FAQ: Cambio de Gestión

Público objetivo: Los departamentos de supply chain y/o planificación.

Última modificación: 19 de diciembre de 2023

Visión General de la Gestión del Cambio

Supply Chain Quantitativa (QSC), tal como fue pionera y defendida por Lokad, difiere significativamente de la perspectiva tradicional. Las diferencias son tanto esenciales como la razón principal por la que Lokad puede ofrecer mejoras tan drásticas en la supply chain. Dicho esto, la gestión del cambio asociada con la implementación de una iniciativa de QSC es más sencilla de lo que nuestros clientes suelen pensar.

Por ejemplo, Lokad elimina muchos puntos de contacto y procesos innecesarios, en lugar de simplemente reemplazar un desperdicio por otro diferente. Así, el cambio a gestionar es, por lo general, doble: primero, adaptarse al hecho de que las mundanas y repetitivas decisiones de supply chain ahora están automatizadas; segundo, aceptar que la calidad de esas decisiones automatizadas supera lo que los empleados solían poder lograr con herramientas alternativas (sistemas heredados, hojas de cálculo y, con frecuencia, una combinación de ambos).

Una iniciativa de QSC es liderada por los Supply Chain Scientists de Lokad. Estos expertos consolidan muchos roles que, típicamente, serían desempeñados por múltiples personas en iniciativas similares con otros proveedores de software. Un Supply Chain Scientist actúa como integrador de sistemas, ingeniero de datos, analista de negocios, data scientist, experto en supply chain y gerente de proyecto (entre otros roles). Los Supply Chain Scientists (SCSs) proporcionan todo el coaching, la formación, la orientación y el apoyo necesarios para que los clientes adopten el enfoque de Supply Chain Quantitativa de Lokad.

El despliegue exitoso de Lokad (en producción) suele generar dos resultados notables: ahorros sustanciales a través de mejores decisiones de supply chain, y ahorros sustanciales de productividad gracias a decisiones de supply chain (en gran medida) automatizadas.

En cuanto a la gestión del cambio, los ahorros en supply chain suelen no ser un problema. La empresa podría, en última instancia, decidir reinvertir el capital de trabajo liberado en otro lugar, pero este tipo de decisión normalmente excede el alcance de la iniciativa de Lokad. Sin embargo, los considerables ahorros de productividad generados por Lokad suelen reinvertirse en otras tareas que aportan un valor añadido mucho mayor para la empresa cliente que el proceso heredado.

En resumen, antes de Lokad, las actividades de los profesionales de supply chain dentro de la empresa cliente se centraban casi exclusivamente en el interior: producir un forecast, convertir el forecast en un plan, ajustar los niveles mínimos/máximos de stock en los SKUs, elaborar órdenes de compra/órdenes de producción/movimientos de stock, etc.

Una vez que Lokad está en producción, la mayoría de las actividades se orientan hacia el exterior: identificar lo que los clientes perciben como calidad del servicio, identificar lo que los proveedores consideran un obstáculo para reducir aún más el precio, identificar lo que los transportistas perciben como las causas fundamentales de su falta de fiabilidad, etc.

Estos conocimientos se incorporan de forma continua a la solución de Lokad mediante el apoyo constante de los SCSs.

Para los ejecutivos de supply chain, el mayor cambio es la eliminación (en gran parte) de la gestión diaria de crisis. La solución de Lokad ofrece decisiones automatizadas diseñadas para tratar casos límite molestos, reduciendo así sustancialmente el tiempo que los ejecutivos deben dedicar para analizar el comportamiento errático del mercado. Esto libera a los ejecutivos de supply chain para que puedan estrategizar los objetivos y proyectos de supply chain, en lugar de microgestionar las consecuencias continuas de decisiones subóptimas.

Preguntas Frecuentes (FAQ)

1. Implementación y Gestión de Proyectos

1.1 ¿Ofrecen servicios de gestión de proyectos de implementación?

Sí. Estos servicios son prestados por los Supply Chain Scientists (SCSs) de Lokad. Estos expertos no solo gestionan la implementación, sino que también encabezan la iniciativa con la empresa cliente. Esto incluye muchas tareas, como proporcionar seguridad cuantitativa a la gestión de supply chain para demostrar la validez de las recetas numéricas de Lokad antes de su despliegue. Los SCSs también suministran materiales de formación para apoyar la adopción de las prácticas y procesos recomendados por Lokad dentro de la empresa cliente.

Además, estos expertos permanecen comprometidos con el éxito a largo plazo de la iniciativa, más allá de la implementación inicial, proporcionando soporte continuo a medida que la iniciativa transita hacia su fase de ‘mejora continua’.

Consulte las conferencias de Lokad sobre el Supply Chain Scientist y Un día en la vida de un Supply Chain Scientist para obtener más información sobre el rol de los SCS en el proceso de optimización.

1.2 ¿Cuál es su cronograma de implementación y qué pasos o fases incluye este cronograma?

De principio a fin, la implementación suele durar alrededor de 6 meses. Lokad distingue la fase de incorporación de la fase de producción. El objetivo de la fase de incorporación es poner en producción la receta numérica de Lokad. Al final de la fase de incorporación, las decisiones de supply chain de interés (definidas en colaboración con el cliente) deberían estar automatizadas.

Desglose del cronograma

La fase de incorporación suele durar 6 meses y se puede dividir en tres subfases de 2 meses:

• Meses 1-2: Configuración del Data Pipeline - La primera subfase es la configuración del data pipeline. El objetivo es crear un pipeline completamente automatizado para la extracción de datos del cliente hacia Lokad. Los dos aspectos más exigentes del data pipeline son establecer la ‘semántica’ de los datos y lograr que el proceso de pipeline sea (casi) perfectamente confiable.

• Meses 3-4: Diseño de la Receta Numérica - La segunda subfase es el diseño de la(s) receta(s) numérica(s) única(s) del cliente, es decir, las piezas de lógica de software que impulsan las decisiones de supply chain. El objetivo es obtener recetas que sean consistentes, confiables y sin tonterías. La redacción de las recetas numéricas iniciales es rápida, y suele durar no más de una o dos semanas.

• Meses 5-6: Dual Run - La tercera subfase es el dual run. La receta numérica ya no produce resultados absurdos, y se han acordado los impulsores económicos que guían la optimización. La receta se ejecuta en paralelo con el proceso heredado. Tras varias semanas de dual run, se adquiere la confianza necesaria para proceder con el despliegue en producción.

Al final de la fase de incorporación - y si se han cumplido todos los pasos - comienza el despliegue en producción. Este despliegue consiste en permitir que la automatización tome el control del proceso heredado.

1.3 ¿Documenta y publica Lokad un plan de gestión de proyectos?

Sí. Todos esos elementos, y más, se recogen en un Manual de Procedimientos Conjunto (JPM) único para la iniciativa. Los Supply Chain Scientists (SCSs) se encargan de iniciar y mantener el JPM durante toda la duración de la iniciativa.

El JPM de Lokad se centra en las preguntas de “¿por qué?”. Los JPM están bien redactados y están pensados para ser en gran parte accesibles incluso para audiencias menos técnicas y/o no especializadas. El JPM captura la esencia de la intención detrás de la iniciativa y consolida conocimientos fundamentales a medida que se adquieren a lo largo de la propia iniciativa.

La postura de Lokad es que muchas (si no la mayoría) de las iniciativas empresariales se ven obstaculizadas por la producción de documentos poco útiles, los cuales, en la práctica, son imposibles de leer (es decir, son tediosos o impenetrablemente técnicos). Dichos documentos no tienen ningún propósito más allá de marcar casillas inventadas. Además, muchos terceros (por ejemplo, integradores, consultores e incluso la burocracia interna) tienen una marcada tendencia a favorecer la cantidad sobre la calidad cuando se trata de la documentación del proyecto.

En contraste, los JPM de Lokad están diseñados para ser tanto legibles como leídos. Los JPM son herramientas que los propios SCSs utilizan para gestionar la iniciativa. Si bien disponemos de pautas extensas sobre lo que se espera encontrar en un JPM, en última instancia, depende de los SCSs tomar decisiones juiciosas sobre qué necesita mayor atención y esfuerzo, considerando las especificidades de la iniciativa.

Consulte la conferencia Escribiendo para Supply Chains para obtener más información sobre la filosofía de documentación de Lokad.

1.4 ¿Es Lokad responsable de mantener y establecer la línea base del plan de gestión de proyectos, sujeto a la aprobación del comité directivo del proyecto? En caso de que surjan desviaciones del plan, ¿las comunicarán claramente junto con opciones de mitigación?

Sí. Las responsabilidades enumeradas son gestionadas por los Supply Chain Scientists (SCSs) de Lokad. Los detalles de la gestión de la comunicación con la empresa cliente suelen depender y definirse en los términos contractuales de la propia iniciativa.

En ocasiones, hay significativamente más empleados involucrados en el lado del cliente del proyecto que en el lado de Lokad, por lo que, para mejorar la productividad de los SCSs que manejan la cuenta, muchos de nuestros clientes designan un único punto de contacto para la iniciativa. Esta persona - o pequeño equipo - se encarga de transmitir la información relevante y de solicitar comentarios pertinentes a todas las partes involucradas en el lado del cliente del proyecto. Para una iniciativa particularmente compleja, Lokad establece un comité directivo dedicado compuesto por miembros clave tanto de Lokad como de la empresa cliente. Aunque esta reunión sirve como un mecanismo para asegurar la aprobación formal, la mayor parte del trabajo sustantivo ocurre fuera del propio comité. Los SCSs suelen interactuar diariamente con varios equipos del lado del cliente. Estos equipos se mantienen actualizados de manera continua sobre cualquier desviación del plan, y se aseguran de que la iniciativa en su conjunto se mantenga en el camino correcto. Estas interacciones diarias son una forma mucho más efectiva de discutir y superar problemas técnicos a medida que surgen, en lugar de intentar investigar grandes lotes de problemas durante una sesión del comité directivo. Por lo tanto, el comité directivo, como tal, actúa como un órgano de supervisión en lugar de un grupo de reflexión para la iniciativa.

Nota: Las iniciativas de supply chain cuantitativa son conocidas por encontrar con frecuencia “desviaciones positivas”. Estas son sorpresas beneficiosas en la receta que se revelan durante el mantenimiento continuo de la iniciativa. Esencialmente, son oportunidades demasiado buenas para dejarlas pasar. Como tal, un beneficio clave del enfoque de comunicación de Lokad es la capacidad de transmitir de forma rápida y eficiente estas desviaciones positivas al cliente a medida que surgen, aumentando así significativamente el impacto y la agilidad de la iniciativa.

1.5 ¿Documentarán el plan de comunicación, que incluye reuniones diarias, informes semanales de estado del grupo de trabajo y sesiones de revisión, así como informes y sesiones de revisión mensuales del comité directivo? ¿Delimitarán los criterios de escalada y asegurarán un acuerdo mutuo entre la empresa cliente y Lokad sobre estos detalles?

Sí. Los Supply Chain Scientists (SCSs) de Lokad son responsables de estas tareas. Los detalles de la gestión de la comunicación dentro de la empresa cliente suelen depender de los términos contractuales de la propia iniciativa.

Lokad participa de buena gana en las reuniones diarias cuando está presente en la sede de la empresa cliente. Sin embargo, normalmente, nuestros SCSs operan en las oficinas de Lokad.

Consolidamos toda la documentación de la iniciativa en un Manual de Procedimientos Conjunto (JPM) que sirve efectivamente como una guía completa para todo el proyecto. El JPM incluye las notas de todas las sesiones de trabajo, incluidos los informes del comité directivo (cuando corresponda).

Aunque Lokad aclara los criterios y pautas de escalada, vale la pena destacar que se espera que un SCS Senior de Lokad se encargue de cualquier pregunta o inquietud sobre la iniciativa. Así, respecto a la escalada, la resolución de un problema preocupante suele escalarse de un SCS Junior a uno Senior. Esto, históricamente, ha resultado suficiente, con muy pocas situaciones que requieran una escalada adicional.

Lokad considera que todos los problemas, por insignificantes que parezcan, merecen un análisis en profundidad. Aunque sus efectos son fáciles de resolver, los problemas menores pueden plantear futuros inconvenientes si no se entienden y abordan las causas raíz. Esto evita que un problema menor se convierta en uno recurrente. Por ello, Lokad favorece poner en la línea del frente a personas altamente capacitadas, capaces de abordar tanto el problema inmediato como de identificar las causas subyacentes. Este enfoque es preferible a depender de personal de soporte no capacitado, que continuamente aborda los mismos problemas, un patrón que demasiadas veces han adoptado muchos proveedores de software empresarial.

Así, el conciso proceso de escalada de Lokad es intencional, garantizando resoluciones rápidas y duraderas.

1.6 ¿Asegurarán que el plan de gestión de proyectos sea aprobado por todas las partes interesadas como parte de la fase de iniciación del proyecto?

Sí. Más en general, los Supply Chain Scientists (SCSs) de Lokad siguen el proceso que se haya negociado y acordado con cada cliente, según los términos contractuales formales. Este principio se aplica a lo largo de toda la iniciativa, desde el inicio hasta la conclusión. La iniciación del proyecto es ciertamente importante, aunque dado que Lokad no requiere un compromiso a largo plazo desde el primer día, este asunto es de menor importancia, especialmente en comparación con nuestros competidores.

Cabe señalar que nunca hemos observado que una supply chain rinda mal debido a la ‘falta’ de burocracia y otros procesos frívolos. Al contrario, las burocracias innecesarias y los procesos insulsos son los problemas más comunes en las supply chains modernas, presentes incluso en empresas que, por otro lado, parecen tener supply chains de alto rendimiento.

1.7 ¿Desplegarán un project manager dedicado de Lokad que esté basado en la sede de la empresa cliente, acompañado de expertos en la materia del producto, analistas de negocios y expertos en interfaces técnicas?

Sí, si tales disposiciones forman parte de los términos contractuales acordados para la iniciativa. Aunque Lokad no se opone a asignar empleados in situ en la sede de la empresa cliente, naturalmente incrementa el coste de la iniciativa. La mayoría de nuestras iniciativas se llevan a cabo de forma remota y se apoyan en visitas mensuales o trimestrales, dependiendo de la escala de la iniciativa. Esta práctica suele ser percibida por todas las partes como más eficiente que estacionar empleados de Lokad en la(s) oficina(s) del cliente todo el tiempo. Cabe señalar que, incluso si Lokad acepta asignar un equipo permanente en la sede de la empresa cliente, los empleados rotarán con el tiempo.

Dichas prácticas benefician a todos los involucrados, ya que los Supply Chain Scientists (SCSs) de Lokad están sujetos a un programa de capacitación continuo. Este programa es fundamental para asegurar que nuestros empleados continúen adquiriendo nuevas habilidades o afinando las antiguas, sin importar la experiencia o antigüedad. Mientras observamos que muchos proveedores de software empresarial permiten que sus empleados operen durante meses, si no años, en sitios remotos del cliente, Lokad está convencido de que esta práctica no es compatible con la provisión confiable y eficiente de programas de capacitación de alta calidad.

En particular, una de las mayores fortalezas de los SCSs de Lokad es su conjunto de habilidades excepcionalmente diverso y amplio. Cada SCS está capacitado para desempeñarse en una variedad de roles, tales como: experto en la materia, analista de negocios, experto en interfaces técnicas, data scientist y consultor de supply chain. Estas funciones normalmente serían cumplidas por múltiples empleados y resultarían en un aumento significativo de costos para el cliente. En Lokad, cada SCS proporciona todos estos servicios.

Como resultado, los SCSs tienden a ser mucho más productivos (menos personas suelen significar menos fricción en la comunicación), así como a generar niveles de rendimiento más altos. En realidad, las supply chain dependen críticamente de la consistencia de extremo a extremo, algo que es mucho más fácil de lograr con un bajo número de empleados.

1.8 Durante la fase de implementación, ¿qué organización propone? ¿Dónde se deben asignar los recursos?

Para una iniciativa típica en Lokad, recomendamos que la empresa cliente designe a un experimentado practitioner de supply chain como coordinador de la iniciativa, y que también designe a un ejecutivo de supply chain como supervisor de la iniciativa. El coordinador actúa como punto de contacto entre el equipo de Supply Chain Scientists (SCSs) de Lokad y la empresa cliente. Inicialmente, el coordinador transmitirá las solicitudes de información y, posteriormente, las solicitudes de feedback. Paralelamente, los SCSs de Lokad trabajan con las recetas numéricas destinadas a producir las decisiones de supply chain de interés.

Recomendamos una reunión semanal para revisar el progreso de la iniciativa hasta que se complete la fase de onboarding. Esta reunión es atendida sistemáticamente por el coordinador, el supervisor y el SCS primario de la cuenta de Lokad. Otros participantes pueden unirse según sea necesario, pero su presencia continua generalmente no es necesaria durante toda la fase de implementación/onboarding.

Algunos recursos de TI deben asignarse para configurar el data pipeline al inicio de la iniciativa. Lokad es más eficiente que la mayoría de sus pares en este aspecto. Por ejemplo, extraemos de forma automática y directa los datos transaccionales del cliente, sin que se requiera ninguna limpieza o preparación del lado del cliente. A menos que la empresa cliente esté experimentando un vendor lock-in, esta configuración técnica requiere menos de 4 semanas de trabajo para un solo colaborador, y a veces mucho menos cuando ya se dispone de un data lake.

Luego, los SCSs necesitarán recopilar insights cualitativos sobre los procesos existentes y los detalles de todas las prioridades y limitaciones de supply chain. Una serie de entrevistas, facilitadas por los coordinadores, se llevará a cabo normalmente para apoyar este proceso. Más adelante, una vez que los SCSs hayan desarrollado la(s) receta(s) numérica(s), se realizará otra serie de entrevistas para revisar las cifras generadas por esas recetas y permitir a los SCSs refinarlas y mejorarlas.

La aportación del supervisor es importante tanto para alinear a Lokad con la estrategia de alto nivel que persigue la empresa como para evitar que la iniciativa se estanque por indecisión. Por ejemplo, Lokad puede proponer varias opciones para modelar los costos asociados con la falta de calidad en el servicio. Podemos explicar las ventajas y desventajas de estas opciones en términos no técnicos, pero en última instancia, se deben tomar algunas decisiones estratégicas.

Naturalmente, todo lo anterior depende de las necesidades específicas de la iniciativa. Estamos abiertos a otros enfoques organizativos si se adaptan mejor al contexto y objetivos específicos de la empresa cliente.

Para más información, Lokad tiene varias conferencias dedicadas a² de una exitosa optimización de supply chain.

2. Resource Management & Requirements

2.1 ¿Cuáles son los requisitos de personal para la implementación del proyecto en la empresa cliente?

Una iniciativa típica de Lokad requiere aproximadamente de 0.5 a 2 FTE (equivalente a tiempo completo) de recursos empleados de la empresa cliente durante los primeros 6 meses – es decir, la fase de onboarding. Una vez que la iniciativa entra en producción, se estima razonablemente que el proyecto seguirá requiriendo al menos 0.25 FTE.

En términos de recursos requeridos en cada etapa de una iniciativa “típica”, durante la fase de onboarding tenemos:

• Meses 1 y 2: La configuración del data pipeline requiere 4 semanas de esfuerzo a tiempo completo por parte de un data officer, típicamente empleado por el departamento de TI del cliente. El data officer debe estar bastante familiarizado con el paisaje aplicativo de la empresa cliente.

• Meses 3 y 4: Diseñar la receta numérica requiere 2 o 3 días por semana por parte del coordinador (lado cliente) de la iniciativa, un mínimo de 10 horas por semana de varios supply chain practitioners para proporcionar insights de alto nivel y, posteriormente, para proporcionar feedback sobre las cifras producidas por Lokad.

• Meses 5 y 6: Los requisitos son esencialmente los mismos que en la fase anterior; sin embargo, el enfoque cambia. El coordinador ahora dedica la mayor parte de su tiempo a preparar el despliegue adecuado y a comunicarse con todos los supply chain practitioners afectados.

Véase también Project Implementation & Management 1.2.

2.2 ¿Se asegura de que se planifique un número adecuado de personal para respaldar la transición del producto?

Sí. Como regla general, Lokad recomienda mantener la misma cantidad de recursos (por ejemplo, los mismos Supply Chain Scientists) al pasar de la fase de onboarding a la fase de producción. El retorno de inversión potencial de una solución bien mantenida y continuamente mejorada es sustancial.

Cabe señalar que, dado que Lokad automatiza las decisiones de supply chain, no existe una urgencia estricta en volver a capacitar a todos los supply chain practitioners del cliente con un nuevo proceso para mantener en funcionamiento la supply chain: la automatización en sí está diseñada para encargarse de eso.

Este enfoque optimizado contrasta marcadamente con las grandes – y costosas – “task forces” que a menudo exigen los proveedores de software empresarial para poner en marcha el sistema.

2.3 ¿Puede garantizar que habrá suficiente personal y recursos de knowledge product (KP) disponibles in situ en la sede de la empresa cliente para respaldar la transición del producto?

Sí, tales disposiciones y requisitos están cubiertos por los términos contractuales específicos, acordados mutuamente para la iniciativa.

Véase también Project Implementation & Management 1.7.

Véase también Resource Management & Requirements 2.2.

2.4 ¿Organiza sesiones de revisión de requisitos con los business product owners para extraer y documentar los requisitos?

Sí. Uno de los primeros objetivos del Supply Chain Scientist es adquirir todos los insights necesarios sobre la supply chain del cliente. Este proceso se lleva a cabo típicamente mediante entrevistas con los stakeholders relevantes, incluidos los business product owners. También intentamos revisar cuidadosamente los documentos existentes (cuando están disponibles) para aprovechar al máximo dichas entrevistas.

Sin embargo, la principal preocupación de Lokad es entender el “problema” que se investiga, algo que no siempre se ve facilitado al enumerar “requisitos”. Por ejemplo, si un cliente menciona que requiere un manejo especial de los “slow movers”, entendemos que el bajo volumen es una preocupación a abordar. Sin embargo, tratar esos SKUs como un caso especial es solo una de las muchas opciones disponibles para abordar esta preocupación.

En este ejemplo, nuestra preferencia sería determinar la verdadera naturaleza de los “slow movers”. De hecho, después de investigar los puntos críticos de la supply chain del cliente, puede darse el caso de que los “slow movers” sean SKUs que han sido mal valorados, empaquetados y/o asignados. Una vez que se comprende mejor el problema (slow movers), la estrategia de intervención cambia completamente, lo que a menudo facilita su abordaje.

Así, aunque Lokad extrae y documenta todos los requisitos del cliente, nuestro enfoque enfatiza en descubrir la verdadera naturaleza del problema, en lugar de aceptar al pie de la letra el estado actual de la supply chain del cliente.

Véase Fall in Love with the Problem, Not the Solution para obtener más información sobre la dicotomía problema-solución.

2.5 ¿Proporciona estimaciones del esfuerzo, costos y cronogramas para funcionalidades que requieran customization, incluidas las interfaces del sistema, y las comparte después del workshop de análisis fit-gap?

Sí. Estas estimaciones se incluyen normalmente en nuestra propuesta comercial inicial. Si se organiza un workshop para preparar la iniciativa, utilizaremos la información del workshop para afinar aún más nuestra propuesta.

La plataforma de Lokad es programática. Así, la implementación está pensada para ser soportada por scripts, escritos en Envision, nuestro DSL (lenguaje de programación específico de dominio) dedicado a la optimización predictiva de supply chains. Como resultado, Lokad está especialmente bien preparado para entregar features e interfaces hechas a la medida, ya sea que esas interfaces estén destinadas a personas o a los sistemas empresariales de la empresa cliente.

A diferencia de la mayoría de software empresarial, la programmability es una característica central para Lokad. Los scripts Envision mencionados no son una “customization” de la solución Lokad en el sentido habitual. Tampoco la presencia de esos scripts representa un alejamiento de la rama principal de desarrollo de la solución Lokad. Más bien, la rica programmability de Lokad es el camino de implementación previsto.

Como resultado, hay un grado de certeza sumamente alto vinculado a nuestras estimaciones (costos, cronograma, etc.). La gran mayoría de los proyectos se mantienen dentro de las estimaciones/presupuesto inicial (en todos los sentidos). Esto contrasta con varios de los competidores de Lokad, para quienes son comunes los retrasos costosos y las reformulaciones de términos.

Véase el estudio de caso sobre el Debacle SAP de Lidl de 500 millones de € para más sobre este punto.

2.6 ¿Implementará y mantendrá una estrategia de retención razonable diseñada para retener al personal clave que realiza los servicios durante el plazo del acuerdo? ¿Mantendrá también planes de sucesión activos para cada una de las posiciones clave del personal de Lokad?

Sí. Retenemos a los empleados durante un promedio de 3.5 años, lo cual es casi el doble de la permanencia laboral comparado con cohortes similares (ingenieros talentosos en TI, o en áreas adjuntas a TI) en mercados semejantes (Norteamérica y Europa Occidental). Este segmento del mercado laboral es ferozmente competitivo y, aunque siempre hay margen de mejora, esto sitúa a Lokad muy por encima de la mayoría de nuestros competidores. Como resultado, la mayoría de las iniciativas de Lokad se benefician de contar con los mismos Supply Chain Scientists (SCSs) de un año al siguiente.

Esta retención se debe a salarios competitivos y a la continua inversión de Lokad en la capacitación de sus equipos. En particular, el contenido de supply chain publicado por Lokad en su propio sitio web, sobre todo nuestra serie de conferencias de supply chain, puede verse como un subproducto del enfoque de Lokad en formar a su propio personal. Generalmente, los proveedores de software empresarial que no tienen materiales de capacitación públicos casi nunca tienen materiales de capacitación privados tampoco (incluso si invariablemente afirman lo contrario).

En cuanto a los planes de sucesión, contamos con dos prácticas importantes. Primero, cada iniciativa de Lokad viene acompañada de un Joint Procedure Manual (JPM). El JPM es el documento principal que usa un nuevo SCS para familiarizarse rápidamente con todos los insights y tecnicismos relevantes de la iniciativa. Segundo, cada iniciativa tiene, en todo momento, tanto un SCS primario como un SCS secundario. Incluso si el SCS secundario no contribuye directamente a la iniciativa, Lokad asigna suficiente tiempo para asegurarse de que esta persona esté lista para hacerse cargo de la iniciativa en caso de que surja la necesidad. Esta práctica mitiga en gran medida las complicaciones relacionadas con ausencias o rotación no planificadas.

3. Roles, Responsibilities & Stakeholder Management

3.1 ¿Qué nivel de cooperación tiene con la empresa cliente?

El nivel de cooperación que tenemos con nuestros clientes varía, pero en general es mucho mayor que el que usualmente se espera de un proveedor de software empresarial. Las preocupaciones de supply chain no son igualmente importantes para todas las empresas, por lo que la colaboración tiende a ser más fuerte en aquellas donde la supply chain es la columna vertebral (reconocida) de sus actividades.

El término “partner” se ha diluido hasta el punto de que incluso los proveedores de productos de software triviales (como el software de control de tiempo) terminan siendo llamados “partner”. Sin embargo, después de uno o dos años, la mayoría de nuestros clientes se refieren a su relación con Lokad como una asociación “genuine” – en el sentido verdadero de la palabra. Tienen caras conocidas en Lokad que han ganado su confianza y, en consecuencia, esas personas – típicamente los Supply Chain Scientists (SCSs) – están íntimamente familiarizadas con su negocio. Además, nuestros resultados son frecuentemente considerados lo suficientemente notables como para ser presentados personalmente al CEO y/o a la junta directiva, incluso en grandes empresas.

La colaboración en curso con Lokad permite a nuestros clientes re-ingeniar positivamente toda su práctica de supply chain. En última instancia, toda la cadena se renueva, impactando positivamente tanto a clientes como a proveedores. Cabe señalar que Lokad no tiene intención de reemplazar la experiencia estratégica crítica que existe en la empresa cliente. Más bien, Lokad desea automatizar el aspecto (o aspectos) más mundano(s) y repetitivo(s) de los procesos de toma de decisiones de supply chain. Este enfoque, posteriormente, libera recursos significativos –y a menudo escasos– de la empresa cliente que pueden ser redirigidos a mejores usos.

3.2 ¿Qué roles y responsabilidades se espera que estén presentes, tanto en la empresa cliente como en Lokad, para maximizar la efectividad de la solución?

Existen 4 roles típicos involucrados en las iniciativas de Supply Chain Quantitativa de Lokad.

• The Supply Chain Leader: Este rol enfatiza la importancia de la implicación de la alta dirección en la iniciativa de Supply Chain Quantitativa. Aunque no se espera que se adentre en los detalles técnicos, esta persona debe comprender y comunicar los insights estratégicos de la iniciativa. Su rol no es crear métricas y KPIs, sino evaluar y cuestionar críticamente las mismas, asegurando la alineación con la estrategia global.

• The Supply Chain Coordinator: Esencial para asegurar el funcionamiento fluido de la iniciativa, esta persona actúa como puente entre varios equipos internos. Su responsabilidad principal es recopilar feedback, comunicarse con los stakeholders y confirmar/aclarar procesos y decisiones. Se asegura de que la iniciativa se alinee con los flujos de trabajo existentes en la empresa, manteniendo, además, una mente abierta ante posibles revisiones futuras de dichos flujos.

• The Data Officer: Los datos son la columna vertebral de la iniciativa de Supply Chain Quantitativa, y esta persona garantiza su accesibilidad y fiabilidad. Encargado de extraer conjuntos de datos integrales (como historiales de ventas y compras), es responsable de automatizar y programar la extracción de datos. Aunque su rol es más intensivo al inicio de la iniciativa, su contribución resulta crucial para su éxito.

• The Supply Chain Scientist: Este rol fusiona los insights del Supply Chain Coordinator con los datos del Data Officer para automatizar los procesos de toma de decisiones de supply chain. Comenzando con la preparación de los datos, el Supply Chain Scientist colabora estrechamente con el Coordinator para aclarar cualquier ambigüedad en los datos. Luego, formaliza estrategias en decisiones accionables, como las cantidades de reorden, e implementa dashboards y KPIs para ofrecer transparencia y control.

Consulte project roles para obtener más información sobre las diferentes designaciones dentro de una iniciativa de Supply Chain Quantitativa.

3.3 ¿Dispone de una tabla RACI (Responsible / Accountable / Consulted / Informed) completa para la fase de implementación y para la fase de producción?

Sí. Esta información puede presentarse explícitamente como una tabla RACI si la empresa cliente lo considera importante.

Más aún, los Supply Chain Scientists (SCSs) internalizan este tipo de matriz para poder tomar decisiones juiciosas y rápidas conforme progresa la iniciativa. En lo que respecta a los problemas relacionados con la optimización de supply chain, lo fundamental es determinar la mejor manera de enmarcar el problema. Posteriormente, el foco se desplaza a identificar quién en la organización está en la mejor posición para abordarlo. Es crucial que todo este análisis se realice rápidamente para mantener el impulso de la iniciativa.

Con este fin, los SCSs de Lokad están designados para encabezar la iniciativa y asumir la responsabilidad sobre la calidad del output generado por la receta numérica de Lokad.

De este modo, se trata de un pequeño núcleo de especialistas altamente capacitados que son responsables de las decisiones de supply chain que genera Lokad –en lugar de un elaborado “sistema” o “proceso” de delegar partes de la responsabilidad entre un gran grupo de stakeholders. La postura de Lokad es que tales sistemas tienden a diluir la responsabilidad, en vez de rigidificarla. Nuestros SCSs están, por lo tanto, capacitados para adoptar y operar con esta responsabilidad, lo que incluye asegurar que los stakeholders relevantes en la empresa cliente sean consultados y estén completamente informados de la iniciativa.

3.4 ¿Documentará los roles y responsabilidades utilizando una matriz RACI (Responsibility, Accountability, Consulted, and Informed) para todos los stakeholders involucrados en el proyecto? ¿Se asegurará de que este documento sea discutido y acordado por todas las partes involucradas?

Sí. Todos esos elementos (y más) se reúnen y documentan en el Joint Procedure Manual (JPM). El JPM es elaborado por los Supply Chain Scientists (SCSs) de Lokad (con insights recopilados directamente de la empresa cliente). En este documento, se detallan los parámetros del rol y la responsabilidad de cada persona.

El JPM también sirve como un recurso continuo para la iniciativa y es redactado por los SCSs asignados a la empresa cliente. Producir este documento con sus propias palabras demuestra que los SCSs han dedicado un tiempo considerable a investigar, diagnosticar y analizar el supply chain y la solución global de la empresa cliente (sin simplemente regurgitar la literatura preexistente de la empresa cliente).

Cualquier revisión al JPM se comparte con la empresa cliente. El propio JPM se discute rutinariamente durante las sesiones de trabajo entre Lokad y la empresa cliente.

En una nota relacionada, nuestra experiencia indica que, en caso de surgir desacuerdos, estos usualmente reflejan un problema organizativo que debe resolverse dentro de la empresa cliente. Por ello, recomendamos que la empresa cliente designe a un Supply Chain Executive para supervisar la iniciativa. Una de sus contribuciones clave es actuar como intermediario cuando surjan tales casos.

3.5 ¿Se asegurará de que el grupo de trabajo del proyecto y los grupos directivos estén formados con recursos asignados de los stakeholders del proyecto? ¿Se asegurará de que el ritmo operativo sea acordado por todas las partes involucradas?

Sí. Como principio general, seguimos cualquier proceso que la empresa cliente considere necesario y que haya sido acordado formalmente. Los elementos acordados (y cualquier cambio realizado a medida que avanza la iniciativa) se documentan en el Joint Procedure Manual (JPM), que incluye detalles respecto al grupo de trabajo del proyecto y los grupos directivos. A través de los Supply Chain Scientists (SCSs) de Lokad, contamos con los recursos necesarios para implementar y monitorear estos procesos.

De modo anecdótico, una de las contribuciones más apreciadas de Lokad es nuestra capacidad para simplificar procesos, sean estos de supply chain o de naturaleza burocrática. Con el tiempo, trabajamos activamente para eliminar capas burocráticas innecesarias de los supply chains de nuestros clientes.

4. System Transition & Go-Live

4.1 ¿Cuál es la duración de la transición desde el kick-off hasta el go-live?

La duración típica de la fase de onboarding es de 6 meses. Esta fase comienza con el kick-off y finaliza cuando Lokad está “en producción”, es decir, cuando nuestras recomendaciones automatizadas de supply chain dirigen eficazmente los procesos de toma de decisiones deseados por el cliente.

Esta duración puede reducirse en 1 mes si ya se dispone de un data lake; un data lake bien construido y documentado puede acortar aún más la fase de onboarding. Por el contrario, esta fase suele incrementarse entre 1 y 3 meses cuando el entorno de software o sistemas del cliente es excesivamente complejo u obsoleto.

Curiosamente, la complejidad del supply chain en sí no tiene tanto impacto como podría parecer, ya que Lokad se esfuerza por definir un alcance lo suficientemente preciso como para que sea factible dentro del plazo previsto. Nuestra experiencia indica que las fases de onboarding que superan los 6 meses ponen la iniciativa en riesgo de estancarse. Por ello, diseñamos activamente el alcance para mitigar este riesgo.

Tales retrasos tienen poco que ver con la configuración técnica de Lokad en sí. En conjunto, el cronograma sugerido no solo cumple propósitos técnicos (automatización de la extracción de datos, prueba de recetas numéricas, etc.), sino que también permite a los Supply Chain Scientists (SCSs) de Lokad familiarizarse completamente con todas las particularidades de la empresa cliente, y a los equipos de supply chain “asimilar” el enfoque de Lokad –lo cual suele representar una desviación del proceso heredado del cliente.

4.2 ¿Cuántas visitas en sitio planifica? ¿Cuántos talleres en sitio planifica?

El número de visitas y talleres realizados en sitio se negocia como parte de los términos contractuales específicos con la empresa cliente, aunque cabe señalar que los costos de viaje pueden afectar las tarifas que Lokad cobra. Por lo tanto, la inclusión de visitas en sitio es, en última instancia, una decisión que debe tomar la empresa cliente, y Lokad se adaptará a la frecuencia deseada.

Cuando el objetivo de la empresa cliente es mantener la iniciativa lo más lean posible, estamos cómodos con una iniciativa totalmente remota, es decir, sin visitas en sitio. Recomendamos este enfoque para empresas más pequeñas (con ingresos anuales inferiores a 100M USD) y para aquellas que generalmente están cómodas con colaboradores remotos (como grandes ecommerce companies). Alrededor de la mitad de las iniciativas realizadas por Lokad pertenecen a esta categoría.

Cuando el objetivo de la empresa cliente es maximizar las probabilidades de gestionar con éxito el cambio, estamos cómodos con visitas cada mes –e incluso más frecuentemente si es necesario. Para empresas grandes (con ingresos anuales superiores a 1B USD), recomendamos al menos una visita/taller en sitio cada trimestre. Este enfoque ayuda a desarrollar una alineación a nivel de toda la empresa, especialmente cuando se trata de equipos numerosos.

Para nuestros clientes en Europa Occidental, tendemos a realizar más visitas (típicamente de un solo día) que talleres cuando estamos en sitio. Para nuestros clientes fuera de Europa Occidental, tendemos a realizar más talleres (típicamente de varios días) que visitas cuando estamos en sitio. Esta diferencia es simplemente una cuestión de los costos de viaje asociados y la logística.

4.3 ¿Cuál es el equilibrio ideal entre reuniones remotas y en sitio?

Para una iniciativa de Supply Chain Quantitativa, la mayoría de las reuniones deberían ser remotas. La mayoría de las reuniones son cortas (30 minutos o menos) y solo involucran a dos participantes: un Supply Chain Scientist de Lokad y un profesional de supply chain de la empresa cliente. Además, las reuniones remotas son beneficiosas para tareas técnicas específicas, ya que todos los participantes tienen acceso a su propia configuración de computadora, incluyendo acceso a monitores grandes. Esto resulta especialmente útil cuando los participantes necesitan investigar informes complejos.

Sin embargo, Lokad no subestima el valor de las reuniones en sitio con los clientes. Las reuniones en sitio a menudo facilitan la transmisión de ideas complejas, la discusión de perspectivas y/o la revisión de las expectativas entre las partes. Por ello, recomendamos adoptar un ritmo regular para las reuniones en sitio (por ejemplo, semanal/mensual/trimestral…). Lokad considera estas reuniones en sitio como eventos significativos, especialmente cuando Lokad es el anfitrión de la empresa cliente.

Este enfoque permite que ambas partes mantengan las reuniones remotas de forma discreta, conveniente y con la frecuencia necesaria.

4.4 ¿Asiste a la empresa cliente en la realización de una verificación de calidad del entorno de producción para evaluar la preparación para el go-live, incluyendo la configuración de interfaces?

Sí. De hecho, Lokad va más allá de simplemente asistir a la empresa cliente en su evaluación de preparación para el go-live. Una de las principales responsabilidades de los Supply Chain Scientists (SCSs) de Lokad es asumir la responsabilidad de la solución de extremo a extremo entregada a la empresa cliente. En otras palabras, aunque un sistema mecanizado (una flota de máquinas) genera los resultados, sigue siendo una persona la que asume la responsabilidad personal del sistema. Esta persona se asegura de la precisión, relevancia y adecuación de la cadena de procesamiento de datos de extremo a extremo, teniendo en cuenta también las preocupaciones generales del negocio del cliente.

Dada su naturaleza propensa a errores, las interfaces de software merecen una atención específica, y el SCS está bien capacitado para ayudar a evaluar su integridad. Lokad evalúa esta integridad en el lado de entrada (cuando Lokad recibe datos históricos de la empresa cliente) y en el lado de salida (cuando Lokad devuelve las decisiones de supply chain a la empresa cliente). Para esta tarea, Lokad aprovecha metodologías y tecnologías específicas.

Consulte programming paradigms for supply chain para entender mejor el tipo de tecnologías que Lokad utiliza para asegurar la preparación para el go-live.

4.5 ¿Prepara el documento de estrategia de transición y migración de producción para gestionar la transición sin fisuras de las operaciones comerciales (desde la aplicación comercial existente a la nueva aplicación comercial) para la empresa cliente?

Sí. La transición se documenta en nuestro Joint Procedure Manual (JPM). Esta extensa documentación, elaborada por los Supply Chain Scientists (SCSs) de Lokad, asegura que tanto los profesionales de supply chain como los ejecutivos de supply chain tengan acceso a materiales bien redactados que expliquen adecuadamente el proceso en términos comprensibles. Los SCSs realizan esfuerzos notables para garantizar que este documento sea accesible para una audiencia no técnica (aunque algunos anexos pueden ser bastante técnicos).

Además, el enfoque de dual-run de Lokad está especialmente diseñado para asegurar una transición suave del proceso heredado a la nueva solución. “Dual-run”, en este contexto, se refiere a la práctica en la que Lokad operará de manera concurrente con el proceso de toma de decisiones heredado en todo el alcance de la iniciativa. Esta práctica es posible únicamente debido a la naturaleza robotizada del proceso de toma de decisiones heredado por Lokad, lo que asegura que las recetas numéricas implementadas por los SCSs de Lokad hayan estado funcionando de manera satisfactoria en condiciones de producción exactas, en todo el alcance, durante semanas previas al go-live real, donde las decisiones de Lokad suplantan al proceso heredado.

Cabe señalar que dicho dual-run típicamente no es posible con tecnologías y metodologías alternativas, como las propuestas por nuestros competidores. De hecho, dado que ellos no robotizan las decisiones de supply chain, los costos adicionales asociados con un dual-run son significativos. Como resultado, el dual-run se realiza, en el mejor de los casos, en un alcance reducido que no refleja genuinamente las condiciones de producción. Por ello, cuando se adopta un enfoque de este tipo, la extensión tardía del alcance conduce invariablemente a incidentes de producción que podrían haberse prevenido por completo con un dual-run de alcance completo.

4.6 ¿Proporciona el alcance, los plazos y los criterios de éxito para el pilot run, para que sean revisados y aprobados por la empresa cliente?

Sí. El alcance siempre se detalla en el acuerdo contractual entre Lokad y la empresa cliente. Por lo general, adopta la forma de un determinado tipo de decisión de supply chain (por ejemplo, la reposición de inventario o la asignación de stock) sobre un conjunto de ubicaciones y/o sobre un conjunto de sistemas de negocio.

El cronograma suele ser inferior a 6 meses (desde el kick-off hasta la producción). Aunque un cronograma proyectado siempre se incluye en nuestra propuesta comercial, puede que no se especifique en el acuerdo contractual. El cronograma vinculante representa un compromiso mutuo, y el ritmo de la iniciativa de Lokad depende de la ejecución oportuna de ciertos pasos por parte de la compañía cliente, en particular la construcción de una tubería de datos hacia Lokad.

En términos de criterios de éxito, la decisión siempre es tomada de manera unilateral por la compañía cliente. Aunque podemos documentar los principios guía que deberían respaldar esta decisión, una decisión no unilateral sería inusual. En pocas palabras, un proveedor no debería estar en posición de decidir que el piloto fue un éxito si el cliente piensa lo contrario.

Ver también Project Implementation & Management 1.2.

Por favor consulte Evaluating the Success of a initiative de Supply Chain Quantitativa para obtener más información sobre este matiz.

4.7 ¿Organizarás la realización de pruebas piloto para asegurar a) la adecuación de los datos, b) la configuración del sistema y la preparación de la aplicación, c) el cumplimiento del proceso/sistema, y d) la idoneidad general?

Sí. Como regla general, tratamos un piloto – destinado a entregar la optimización de supply chain – exactamente como trataríamos una iniciativa ‘real’ destinada a ser llevada a producción. A todos los efectos, en lo que respecta a la optimización de supply chain, un piloto adecuado es indistinguible de una configuración de pre-producción aprobada para uso en producción.

El equipo de Supply Chain Scientists (SCSs) de Lokad es responsable de todo lo anterior. Según nuestra experiencia, la adecuación de los datos rara vez es un problema en las compañías que se digitalizaron hace muchos años (si no décadas). Siempre que exista un sistema de negocio para rastrear lo que se compra, produce, almacena y vende, la iniciativa casi garantiza disponer de datos adecuados. El desafío es dar sentido a los datos que originalmente no se recopilaron para apoyar la optimización de supply chain.

Ver bad data para obtener más información sobre este punto.

5. Change & Risk Management

5.1 ¿Qué apoyo pueden ofrecer a la compañía cliente para ayudar a gestionar la gestión del cambio asociada con la implementación de la iniciativa?

Todos los clientes cuentan con el compromiso total de los Supply Chain Scientists (SCSs) de Lokad, quienes están capacitados para manejar los requisitos técnicos y no técnicos de una iniciativa de optimización de supply chain. Los SCSs asisten en el proceso de gestión del cambio de diversas maneras, incluyendo:

• Proponer mejoras en los procesos existentes para los profesionales de supply chain empleados por la compañía cliente.
• Producir materiales de capacitación para integrar a los miembros/equipos de la compañía cliente.
• Asistir a la gestión de supply chain cuantificando, en dólares o euros (o en la moneda que el cliente elija), el impacto de los cambios aportados a supply chain.

Cabe destacar que la gestión del cambio puede representar un compromiso de tiempo significativo para un SCS. Aunque cada SCS posee habilidades y experiencia únicas para ayudar al liderazgo de supply chain en la gestión del cambio, este deber compite con todas sus demás responsabilidades.

Así, los términos contractuales negociados entre Lokad y cada cliente especifican la cantidad de recursos – es decir, el dimensionamiento del equipo de SCSs – que estará disponible para apoyar la iniciativa. Nuestras propuestas comerciales suelen prever que los SCSs proporcionen cierto apoyo en la gestión del cambio. Sin embargo, nuestras propuestas generalmente no reflejan ningún tipo de apoyo a gran escala para la gestión del cambio, a menos que el cliente lo solicite explícitamente.

5.2 Durante la fase de producción, ¿cuál es tu visión para la gestión del cambio? ¿Cuáles son los principales hitos? ¿Cómo se ve la nueva organización tras la implementación exitosa de la nueva solución?

Una vez que Lokad esté en producción, toda una serie de decisiones de supply chain se automatizan. El objetivo es transformar la práctica de supply chain en una empresa capitalista. Cada hora dedicada por un profesional de supply chain debería contribuir a la mejora continua de las recetas numéricas. Esto supone una desviación de la práctica ‘convencional’ de supply chain, en la que la gran mayoría de los esfuerzos en un día se destinan a mantener a la compañía en funcionamiento por un día más. Naturalmente, la transición hacia esta forma de supply chain que aporta valor es gradual.

• El primer hito es lograr que los profesionales de supply chain reconozcan que Lokad les permite descartar la mayor parte del proceso heredado. Por ejemplo, tiene sentido revisar las cantidades de reposición diarias cuando dichas cantidades son frecuentemente incorrectas. Sin embargo, por diseño, las cantidades de Lokad ya son sólidas y no requieren una revisión adicional. De hecho, un 0% de error en las cifras que genera Lokad es el criterio principal para el inicio en producción. La confianza que los profesionales de supply chain pueden depositar en las cifras de Lokad, naturalmente, libera mucho tiempo que puede emplearse de forma más conveniente.

• El segundo hito consiste en tener algunos “early adopters” entre los profesionales de supply chain. Normalmente, se trata de personas que logran separarse rápidamente del proceso heredado que no añade valor – por ejemplo, revisar manualmente las cifras – para centrarse en la mejora continua de supply chain mediante sus recetas numéricas. Ellos pueden comenzar a abordar numerosas cuestiones importantes más allá de aspectos técnicos menores (por ejemplo, ¿está la compañía cliente evaluando su calidad de servicio desde la perspectiva correcta?).

• El tercer hito es lograr que la mayoría de los profesionales de supply chain miren hacia el exterior (clientes y proveedores) en lugar de hacia el interior. En última instancia, supply chain debe ofrecer una alineación que trascienda los límites de la compañía cliente. Esto amplía el conjunto de conocimientos recopilados y ayuda a refinar aún más las recetas numéricas.

La nueva organización se asemeja mucho más a una empresa de software. Hay pocas tareas repetitivas de supply chain que se manejen manualmente, ya que estas se han automatizado. También hay muchas menos emergencias (nuevamente, debido a la automatización). La reducción de tareas rutinarias conlleva un aumento en la variedad de funciones para el profesional de supply chain. Típicamente, esto se traduce en menos tiempo y esfuerzo dedicados al control de supply chain, pero se espera que la dirección capacite a los empleados para que puedan capitalizar el tiempo y esfuerzo adicional disponible.

Ver (Software) Product-oriented Delivery for Supply Chain para obtener más información sobre esta transición.

5.3 ¿Cómo gestionas el cambio en el flujo de trabajo para los usuarios finales? Primero, con la incorporación a Lokad, y segundo con la evolución propia de Lokad.

Por diseño, las decisiones de supply chain generadas por Lokad no requieren flujos de trabajo. De hecho, automatizar todos los pasos involucrados en la generación de las decisiones de supply chain es el arreglo deseado.

Sin embargo, si el cliente lo solicita explícitamente, Lokad es capaz de introducir un “flujo de trabajo” que refleje al proceso heredado. Esto, hay que entenderlo, es únicamente para facilitar la gestión del cambio, y de ninguna manera es un requisito para el éxito de la receta numérica. A medida que los empleados del cliente se familiaricen – y desarrollen mayor confianza en – las decisiones que genera Lokad, el “flujo de trabajo” podrá simplificarse gradualmente, hasta eliminarse por completo.

Respecto a la evolución de Lokad, nuestra plataforma es programática y está gestionada por Envision (nuestro lenguaje de programación específico de dominio). Cualquier cambio/actualización a Envision se realiza mediante scripts automatizados, y este proceso está programado de tal forma que las iniciativas de supply chain que alberga Lokad quedan intactas.

5.4 ¿Pueden mantener un registro de Issues & Risks que incluya un plan de mitigación, tareas, responsabilidades, cronogramas y estados (not started, in-progress, closed, on-hold)? ¿Será el Project Manager de Lokad el responsable de seguir todos los Issues & Risks y asegurar resoluciones oportunas o gestionar escalaciones cuando sea necesario?

Sí. La plataforma de Lokad cuenta con su propio gestor interno de issues/tickets/tareas. Esta función ofrece todas las capacidades habituales que se espera de una herramienta de este tipo, tales como gestionar estados, prioridades, asignaciones, notificaciones, etc. Además, mantenemos por separado un Joint Procedure Manual (JPM) que proporciona una presentación completa y bien organizada de la iniciativa, con todos los cronogramas relevantes de alto nivel. Los Supply Chain Scientists (SCSs) de Lokad son responsables de la supervisión del gestor de tareas. Se aseguran de que los problemas y preocupaciones se atiendan rápidamente.

Las escalaciones son posibles, pero raras. El mismo SCS que gestiona/revisa las tareas también las resolverá. Los SCSs senior en Lokad desempeñan una amplia variedad de roles: experto en supply chain, data engineer, data integrator, business analyst, data scientist, project manager, change consultant, etc.

La facilidad para contactar a los SCSs es algo que nuestros clientes citan rutinariamente como un gran aspecto positivo. El cliente puede interactuar de inmediato con la persona encargada de supervisar la resolución satisfactoria de cualquier problema, en lugar de tener que navegar a través de varias capas de burocracia para, con suerte, hablar con alguien capaz de ayudarle.

En caso de que surja un problema que requiera habilidades fuera de la experiencia de un SCS (por ejemplo, un problema técnico con la arquitectura de la plataforma), ellos aún supervisan la resolución oportuna del problema y actúan como el primer punto de contacto para el cliente respectivo.

5.5 ¿Ofrecen consultoría de gestión del cambio organizacional para abordar la introducción y modificación de procesos de negocio, así como la desactivación de procesos existentes?

Sí, si la compañía cliente desea que su asociación con Lokad incluya servicios de consultoría en gestión del cambio. Cabe señalar que la principal experiencia de Lokad radica en la optimización predictiva de supply chain y no en la gestión del cambio. Nuestro enfoque para la gestión del cambio es también más convencional que nuestras prácticas de supply chain. Este enfoque, de ser implementado, limitaría la cantidad de terceros involucrados en el proyecto.

Alternativamente, si la compañía cliente prefiere contar con los servicios de un especialista en gestión del cambio para complementar a Lokad, la apoyaremos compartiendo todo lo que la compañía considere prudente.

6. Customization & System Functionality

6.1 ¿Organizan sesiones para priorizar los requisitos de personalización, asegurando una comprensión de los impactos en el negocio debido a las brechas del producto y alcanzando un acuerdo mutuo sobre la prioridad para liberar personalizaciones?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. De hecho, Lokad se destaca en dos frentes en lo que respecta a esta priorización. Primero, un SCS es capaz de implementar de forma independiente la personalización y, por lo tanto, puede ofrecer ideas claras sobre lo que está en juego en términos de recursos y cronograma.

Esto mejora en gran medida la calidad de la priorización, ya que la compañía cliente se beneficia de un experto que puede equilibrar de forma inmediata los beneficios de cualquier cambio en supply chain con los costos asociados a dicho cambio.

Segundo, “Supply Chain Quantitativa” – la filosofía global de Lokad – enfatiza una perspectiva puramente financiera. Por ello, el SCS apoya a la compañía cliente en proporcionar estimaciones cuantitativas (en dólares o euros) del impacto de un posible cambio a implementar en la solución. Esta estrategia refina la iniciativa al evitar el tradicional cuello de botella de debatir qué debería priorizarse. En su lugar, Lokad agiliza este proceso al dar prioridad a los problemas que resultan en el mayor impacto financiero.

6.2 ¿Pueden realizar un estudio fit-gap de todos los procesos de negocio para identificar oportunidades de automatización, documentar los procesos futuros deseados y determinar brechas en la funcionalidad del producto? ¿Pueden sugerir soluciones alternativas aceptables cuando se identifican brechas en la funcionalidad del producto?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Si bien se llevará a cabo un estudio inicial al inicio de la iniciativa, este proceso continúa a lo largo de la fase de producción. Es parte de nuestro enfoque perseguir mejoras continuas de la solución.

En lo que respecta a la optimización de supply chain, las brechas rara vez se tratan de ‘funcionalidad’, sino más bien de ‘desempeño’. Por ejemplo, el desafío no es únicamente generar cantidades de reposición (funcionalidad), sino garantizar que las cantidades generadas sean las más rentables (desempeño).

Así, los SCSs se encargan de identificar y abordar las ‘brechas de desempeño’, que a veces requieren funcionalidad adicional o una reingeniería de la solución. Esto puede implicar agregar o eliminar características para optimizar el rendimiento general.

En una nota relacionada, la plataforma de Lokad es programática. Por lo tanto, cualquier ‘brecha de funcionalidad’ percibida puede abordarse introduciendo (o ajustando) unas pocas líneas de código de Envision. Esta programabilidad es precisamente lo que permite a Lokad proporcionar soluciones hechas a la medida para cada cliente.

6.3 ¿Pueden proporcionar una agenda detallada para los talleres de análisis fit-gap del proceso, incluyendo las expectativas del SME (Subject Matter Expert) por parte del cliente, al menos una semana antes de que comiencen los talleres?

Sí. Los Supply Chain Scientists (SCSs) de Lokad proporcionan una agenda para cada taller. Nos aseguramos de que la agenda se comunique al menos una semana antes del evento. Si la compañía cliente ofrece instrucciones explícitas, como un plazo para entregar la(s) agenda(s), las seguiremos. En ausencia de instrucciones, estructuraremos los talleres (incluyendo el cronograma y la transmisión de todos los pasos necesarios del lado del cliente) de manera inteligente y profesional.

6.4 ¿Garantizan que los documentos de requisitos de personalización del producto sean revisados y aprobados conjuntamente por la compañía cliente?

Sí, estos documentos serán proporcionados a – y posteriormente aprobados por – la compañía cliente.

Tenga en cuenta que las elecciones de diseño de la plataforma de Lokad eliminan en gran medida la necesidad de ‘customization’ – al menos, en el sentido en que este término se entiende comúnmente en el mundo del software empresarial. La plataforma de Lokad es programática, utilizando Envision – nuestro DSL (lenguaje de programación específico de dominio) dedicado a la optimización predictiva de supply chain.

Por lo tanto, las soluciones de Lokad siempre están ‘customized’ en el sentido de que están totalmente hechas a la medida de las necesidades específicas de la empresa cliente. Sin embargo, tal personalización se entrega de modo que mantiene la solución como parte de la línea principal de productos de Lokad. Este es el enfoque preferido (y deliberadamente diseñado) de Lokad, y no presenta problemas de mantenibilidad.

6.5 ¿Asisten a la empresa cliente en establecer la conectividad de interfaces con sistemas externos, y en probar y certificar las interfaces?

Sí. Los Supply Chain Scientists (SCSs) de Lokad proporcionan soporte para configurar, probar, validar y documentar las interfaces entre los sistemas operados por la empresa cliente y Lokad. Los SCSs podrían ser complementados por algunos recursos internos de TI en Lokad para los aspectos técnicos de muy bajo nivel, tales como redes o protocolos de seguridad.

Las interfaces del sistema normalmente no son ‘certificadas’ por un organismo de certificación externo. Las interfaces se especifican formalmente mediante especificaciones técnicas acordadas conjuntamente entre el departamento de TI de la empresa cliente y Lokad. Estas especificaciones técnicas respaldan las obligaciones mutuas de las empresas: en resumen, la empresa cliente se compromete a proporcionar los datos requeridos a Lokad a tiempo; Lokad, a su vez, se compromete a devolver los resultados también a tiempo.

6.6 ¿Proporcionan documentos de especificación de interfaces durante los talleres, incluyendo mensajes de ejemplo?

Sí, Lokad proporciona especificaciones de interfaces durante los talleres. Los mensajes de ejemplo se pueden incluir si la empresa cliente lo desea.

Sin embargo, dada la naturaleza del servicio de Lokad, los “mensajes de ejemplo” probablemente adoptarán la forma de tablas, ya que esto representa de manera más precisa la salida que Lokad genera para la empresa cliente. Para referencia, la gran mayoría de las especificaciones técnicas para las interfaces se centrarán en las tablas y sus formato(s), así como en los patrones de extracción de tablas y los horarios de transferencia.

6.7 ¿Comparten los procesos de solicitud de cambios y de gestión de versiones?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Es importante señalar que Lokad tiene dos niveles de cambios y versiones, lo cual es diferente del software empresarial típico.

En primer lugar, los cambios realizados específicamente para los clientes son implementados por los mismos SCSs. Estos cambios ocurren con frecuencia, a menudo varias veces al día, particularmente durante la fase de incorporación. Dichos cambios son en respuesta directa a las necesidades de la empresa cliente y requieren una comunicación considerable entre ambas partes.

En segundo lugar, realizamos actualizaciones a la plataforma de Lokad, típicamente mediante actualizaciones a Envision - nuestro DSL (lenguaje de programación específico de dominio) dedicado a la optimización predictiva de supply chain. Estos cambios están diseñados para ser transparentes para las empresas cliente. Si se desea, se pueden proporcionar los detalles sobre estas actualizaciones, y gran parte de esta información se hace pública.

Consulte Envision VM Environment and General Architecture para obtener más información sobre la evolución de la plataforma de Lokad.

7. Pruebas de Aceptación de Usuario (UAT)

7.1 ¿Asisten a la empresa cliente en la configuración del entorno de prueba de UAT (User Acceptance Testing) con datos específicos del contexto y configuraciones del sistema?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Lokad ofrece innovaciones metodológicas y técnicas únicas en apoyo de esto.

En términos de metodología, favorecemos el diseño de listas priorizadas, donde los elementos se ordenan por un retorno de inversión (ROI) decreciente para la empresa. Este aspecto es crítico para asegurar que el tiempo de los usuarios finales no se desperdicie revisando grandes cantidades de datos mayormente irrelevantes.

En términos de tecnología, la plataforma de Lokad ha sido diseñada específicamente para soportar de forma concurrente múltiples entornos para cualquier iniciativa dada. Estos entornos son una característica nativa de nuestra plataforma SaaS multi-tenant, y por lo tanto pueden ser introducidos con una sobrecarga mínima, tanto en términos de recursos de computación como de tiempo de administración del sistema.

Véase también User Acceptance Testing 7.3.

7.2 ¿Configuran los entornos de pre-producción, producción y entrenamiento de UAT (User Acceptance Testing) de acuerdo con los procesos ToBe definidos?

Sí. Dada la rica capacidad de programación de la plataforma de Lokad, podemos ejercer control total sobre las configuraciones. Esto es posible gracias a Envision - nuestro DSL (lenguaje de programación específico de dominio) dedicado a la optimización predictiva de supply chain.

Este enfoque permite que diferentes entornos utilicen la misma configuración para todas las partes que no están sujetas a cambios, utilizando el mismo código siempre que sea posible. Esto reduce en gran medida las diferencias accidentales entre entornos, las cuales pueden confundir a los usuarios y comprometer la integridad del proceso de UAT.

Además, avanzar una configuración de una etapa a otra es sencillo con nuestro diseño. Utilizar una base de código para los cambios de configuración es más eficiente que los métodos tradicionales de interfaz de usuario.

7.3 ¿Proporcionan entornos separados de UAT (User Acceptance Testing), migración de datos, etapa de producción (pre-prod), producción y entrenamiento para el producto (incluidas las interfaces requeridas) a la empresa cliente y a sistemas externos?

Sí. La plataforma de Lokad ha sido diseñada específicamente para soportar de forma concurrente múltiples entornos para cualquier iniciativa dada. Estos entornos son una característica nativa de nuestra plataforma SaaS multi-tenant, y por lo tanto pueden ser introducidos con una sobrecarga mínima, tanto en términos de recursos de computación como de tiempo de administración del sistema.

Con Lokad, duplicar todo el entorno de producción, incluidos todos los datos de producción, se realiza sin duplicar la huella de almacenamiento de datos. Internamente, los datos que son idénticos entre los dos entornos se mutualizan. Además, nuestro diseño de tiempo constante asegura que la carga de trabajo de un entorno no afecte negativamente el rendimiento de otro entorno.

Sin embargo, la mayoría de los proveedores de software empresarial evitan todo el problema simplemente ‘clonando’ la configuración principal. Clonar - o duplicar directamente - es fácil pero derrochador. Clonar significa que la cantidad de recursos (personas y máquinas) aumenta de manera lineal con el número de entornos — por ejemplo, tres entornos triplican los costos originales. Para cualquier supply chain de gran tamaño, esto se traduce en costos considerables.

7.4 ¿Garantizan la resolución oportuna de todos los defectos para asegurar que el UAT (User Acceptance Testing) se complete dentro de los plazos mutuamente acordados?

Sí, siempre y cuando se puedan acordar definiciones matizadas de ‘resolución’ y ‘defecto’. En general, los Supply Chain Scientists (SCSs) de Lokad están a cargo de resolver todos los problemas que socavan el objetivo central de la iniciativa: aumentar el retorno de inversión. En un escenario típico, el SCS propone una acción adecuada y un plazo correspondiente, que la empresa cliente valida o actualiza a su discreción.

Es fundamental destacar que, cuando se trata de supply chain, no existen soluciones perfectas, solo compensaciones mejores o peores. En otras palabras, no se puede resolver realmente un problema en el que dos o más valores estén en completa oposición.

Por ejemplo, el inventario perecedero caducado es un desperdicio, pero al manejar productos perecederos, dicho desperdicio no puede ser completamente eliminado sin crear un problema consecuente en la calidad del servicio. Se debe encontrar un equilibrio entre el dead stock y el faltante de stock. Sin embargo, tanto el ‘dead stock’ como el ‘faltante de stock’ son, en cierto sentido, defectos.

En resumen, los SCSs pueden resolver problemas ‘mundanos’ a medida que surgen, como arreglar un error de parsing al leer un archivo (un bug de software). Sin embargo, el objetivo general de una solución de Supply Chain Quantitativa no es “resolver problemas”, sino aumentar el retorno de inversión (en dólares o euros). Lokad logra este tipo de “resolución” a través de un enfoque inteligente y financieramente impulsado para las compensaciones en la supply chain.

7.5 ¿Asisten a la empresa cliente en la revisión de los escenarios, casos de prueba y datos de prueba de UAT (User Acceptance Testing)?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso.

Sin embargo, en lo que respecta a la optimización de supply chain, los conjuntos de datos más pequeños que la configuración completa de producción generalmente no son suficientes. En la práctica, los escenarios, casos de prueba y datos de prueba deben ser (casi) tan grandes como la configuración de producción para reflejar una perspectiva end-to-end de supply chain. Este requisito no tiene nada que ver con Lokad; es simplemente la naturaleza de supply chain.

7.6 ¿Garantizan soporte in situ en la sede de la empresa cliente durante la fase de UAT (User Acceptance Testing)?

Sí. El soporte in situ se rige por el acuerdo contractual entre Lokad y la empresa cliente. Este aspecto se negocia siempre caso por cliente.

Cabe señalar que una iniciativa de Supply Chain Quantitativa con Lokad presenta una mejora continua de supply chain, por lo que no existe un periodo fijo de UAT. Las pruebas típicamente comienzan al final del segundo mes, alcanzan su pico en el cuarto mes, y luego se estabilizan a partir del sexto mes en adelante.

Al dedicar recursos continuos al perfeccionamiento de nuestras recetas numéricas (algoritmos dedicados a optimizar supply chain), Lokad asegura que cada empresa cliente cuente con una iniciativa actualizada.

Véase también Project Implementation & Management 1.7.

8. Soporte post-implementación y auditoría

8.1 ¿Pueden garantizar que las observaciones de las ejecuciones piloto se documenten, y que cualquier punto de acción se asigne a las partes interesadas correspondientes a través de los departamentos Técnico, TI y de Proveedores de la empresa cliente, y que también se haga seguimiento hasta su cierre?

Sí. Los Supply Chain Scientists (SCSs) de Lokad crean y mantienen un Manual de Procedimientos Conjunto (JPM) para cada iniciativa. Incluye todas las ideas pertinentes para la iniciativa. Es importante que el JPM esté diseñado para ser accesible a audiencias no técnicas (aunque algunas secciones y anexos sean bastante técnicos).

Los puntos de acción de alto nivel se documentan en el JPM. Sin embargo, los puntos de acción menores se manejan típicamente con el gestor de tareas en la plataforma de Lokad. Estos puntos menores son de corta duración y el gestor de tareas facilita su seguimiento y cierre mejor que el JPM.

8.2 ¿Pueden garantizar que se disponga de suficientes informes de calidad y cumplimiento para monitorear el uso y la adopción del sistema?

Sí. Los Supply Chain Scientists (SCSs) de Lokad normalmente implementan instrumentación dedicada para este propósito durante la etapa final de incorporación, justo antes del inicio oficial.

Además, Lokad puede rastrear la alineación entre las decisiones de supply chain que genera y las decisiones reales tomadas en la supply chain. Esto se hace para identificar posibles fuentes de divergencia, tales como bugs o fallos en los sistemas de la empresa cliente, que podrían afectar la implementación de las recomendaciones de Lokad.

8.3 ¿Realizarán una auditoría anual de la aplicación y proporcionarán retroalimentación sobre la mejora del uso y la adopción por parte del usuario final del sistema, con el fin de lograr el ROI (retorno de inversión) más rápidamente?

Sí, una auditoría anual de toda la solución (end-to-end) es un procedimiento operativo estándar. Dicho esto, los Supply Chain Scientists (SCSs) de Lokad suelen auditar toda la solución varias veces a lo largo del año. La auditoría anual generalmente conduce a una presentación detallada de la hoja de ruta para el liderazgo del cliente. Esto está en línea con nuestro enfoque de mejora continua para cada iniciativa.

En cuanto al uso, en la práctica, los SCSs implementan proactivamente herramientas dedicadas desde el principio para monitorear el uso, la adopción y el cumplimiento de las decisiones de supply chain que genera Lokad. Si bien una auditoría anual presenta una excelente oportunidad para realizar los ajustes necesarios, nuestros SCSs son muy proactivos en lo que respecta a la adopción de las recomendaciones de supply chain de Lokad. Este asunto se discutirá durante nuestras sesiones de trabajo semanales, ya que la adopción de las recomendaciones de Lokad es el principal impulsor del aumento del ROI en una iniciativa de Supply Chain Quantitativa.

8.4 ¿Pueden garantizar que el equipo de soporte de producto dedicado, basado in situ en la sede de la empresa cliente, continúe apoyando el producto durante al menos 6 meses después del lanzamiento?

Sí. El equipo de Supply Chain Scientists (SCSs) de Lokad se encarga de esta tarea. Nuestros SCSs están ampliamente capacitados tanto para mejorar continuamente la iniciativa como para proporcionar soporte continuo al cliente. La presencia continua in situ de los SCSs se negociará y aclarará en el acuerdo contractual con el cliente, si este es algo que el cliente desea seguir.

En una nota relacionada, Lokad recomienda encarecidamente mantener un compromiso activo y continuo con la mejora de la solución, particularmente del lado del cliente. El desmantelamiento de los esfuerzos de mejora continua, según nuestra experiencia, debilitará la fortaleza de la iniciativa. Cualquier cambio del lado del cliente, incluidos ajustes modestos en el panorama aplicativo o restricciones, puede impactar la calidad de las decisiones generadas por Lokad; por lo tanto, se aconseja una vigilancia activa y una mejora continua.

Véase también Project Implementation & Management 1.7.

9. Gestión de Incidentes y Defectos

9.1 ¿Pueden garantizar que todos los defectos imprescindibles y solicitudes de cambio (elementos críticos y de alta prioridad) se aborden como prioridad y se entreguen, para evitar cualquier retraso en los plazos de lanzamiento de la empresa cliente?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Nuestra plataforma está diseñada de tal manera que les permite abordar defectos y solicitudes de cambio de forma rápida y autónoma.

La plataforma de Lokad es programática, lo cual es posible gracias a Envision - nuestro DSL (lenguaje de programación específico de dominio) dedicado a la optimización predictiva de supply chains. Esta capacidad de programación significa que los SCSs pueden entregar soluciones y aplicar los cambios solicitados a la iniciativa de manera rápida y con un nivel de precisión no común en el software empresarial.

Más allá de la tecnología, los SCSs de Lokad están capacitados para cumplir una serie de roles clave, lo que naturalmente reduce el número de personas necesarias para abordar los defectos y las solicitudes de cambio. Estos roles incluyen supply chain expert, business analyst, data scientist, data engineer y system integrator. Así, están bien entrenados para proporcionar soluciones y actualizaciones, teniendo siempre en cuenta las principales prioridades del cliente.

Ver también Customization & System Functionality 6.2.

9.2 ¿Pueden implementar un mecanismo de monitoreo de defectos para garantizar el cierre oportuno de todos los defectos y los problemas de usabilidad?

Sí, la plataforma de Lokad viene con su propio sistema de gestión de task / ticket / issue. Estas capacidades nos otorgan la posibilidad de seguir de manera precisa la resolución oportuna de los issues. Dichas resoluciones son atendidas por los equipos de Supply Chain Scientists (SCSs) empleados por Lokad.

Sin embargo, es importante no agrupar juntos “defectos” y “problemas de usabilidad”. Por ejemplo, un inaccurate demand forecast es un “defecto”. Está impactando negativamente el supply chain. Sin embargo, dependiendo de las condiciones del mercado en las que opere la empresa cliente, este “defecto” puede que nunca se solucione, sino solo mitigarse. Cuando se trata de la optimización predictiva de supply chains, las soluciones siempre implican un trade-off, donde al resolver un defecto se crea otro defecto (con suerte, uno menor).

En contraste, los problemas de usabilidad son, por lo general, sencillos de abordar. Así, para esta clase de problemas, estamos dispuestos y comprometidos a garantizar una resolución oportuna, ya que abordar el problema no suele generar otro issue.

9.3 ¿Pueden garantizar que los defectos encontrados durante las pruebas de las versiones (previas a producción) sean atendidos y rectificados de manera oportuna, de modo que no afecten el cronograma de la empresa cliente para la puesta en marcha de la versión?

Sí. Si los defectos identificados conciernen al código específico de la empresa cliente (escrito en Envision), entonces los defectos serán rectificados por los Supply Chain Scientists (SCSs) de Lokad. Si los defectos identificados conciernen a la plataforma de Lokad, entonces los defectos serán rectificados por los equipos de ingeniería de software de Lokad.

En cualquier caso, el proceso de lanzamiento de Lokad implica pruebas exhaustivas para asegurarse de que los defectos sean identificados y corregidos antes de la versión (puesta en marcha).

9.4 ¿Cómo abordarán los incidentes que pueda plantear la empresa cliente a través de alguno de los siguientes canales: teléfono, email, office communicator y/o entrada directa en la Incident Management Tool?

Los Supply Chain Scientists (SCSs) tratan todos los informes de incidentes – sin importar su fuente – con la máxima seriedad. El acuerdo contractual entre Lokad y la empresa cliente especificará cuántos SCSs se asignarán al proyecto, así como las horas por semana en las que el cliente puede esperar contar con soporte directo.

La resolución de un incidente típico comienza con un SCS creando una nueva entrada en el gestor de task/ticket/issue. Esto asegura que exista trazabilidad para el incidente.

A continuación, el SCS diagnosticará el problema. Si el problema requiere una solución por parte de Lokad, el SCS movilizará de inmediato los recursos necesarios para resolver el issue, normalmente el propio SCS.

Finalmente, una vez que el issue ha sido abordado, el SCS evaluará la verdadera causa raíz del issue reportado, incluso si el informe finalmente se diagnosticó como un no-issue. Normalmente, existe algún issue subyacente que necesita ser atendido. Al abordar la causa raíz más profunda, Lokad elimina proactivamente issues similares en el futuro.

9.5 Si se reporta un defecto fuera de la Incident Management Tool – a través de otro canal como email – ¿registrarán el defecto en la herramienta tan pronto como se presente para un seguimiento y cumplimiento adecuados?

Sí. Es práctica estándar crear una entrada correspondiente dentro de la plataforma de Lokad cuando recibimos un informe a través de un canal distinto al gestor de task/ticket/issue. Esta práctica facilita un seguimiento y cumplimiento exhaustivos.