FAQ: Gestión del cambio

Una iniciativa con Lokad tiene como objetivo optimizar el supply chain del cliente con una toma de decisiones superior y automatizada - reemplazando típicamente tareas diarias mundanas como órdenes de compra y elecciones de asignación de stock. Esta página aborda preguntas e inquietudes sobre el cambio que esta iniciativa trae, y sobre cómo gestionarlo eficazmente. Los expertos de Lokad permanecen, en todo momento, disponibles para ayudar a los clientes a navegar por el proceso.

Audiencia 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 (SCQ), tal como ha sido pionera y promovida por Lokad, difiere significativamente de la perspectiva tradicional. Las diferencias son tanto esenciales como las razones fundamentales por las cuales Lokad puede ofrecer mejoras tan drásticas al supply chain. Dicho esto, la gestión del cambio asociada con la implementación de una iniciativa de SCQ 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 típicamente doble: primero, ajustarse al hecho de que las decisiones mundanas y repetitivas del supply chain ahora están automatizadas; segundo, aceptar que la calidad de esas decisiones automatizadas supera lo que los empleados solían ser capaces de lograr con herramientas alternativas (sistemas heredados, hojas de cálculo y, a menudo, algo de ambos).

Una iniciativa de SCQ es liderada por los Supply Chain Scientists. Estos expertos consolidan muchos roles que normalmente serían desempeñados por múltiples personas en iniciativas similares con otros proveedores de software. Un Supply Chain Scientist funciona como integrador de sistemas, ingeniero de datos, analista de negocios, data scientist, experto en supply chain y gestor de proyectos (entre otros roles). Los Supply Chain Scientists (SCSs) proporcionan toda la mentoría, capacitación, orientación y soporte necesarios para que los clientes adopten el enfoque de Supply Chain Quantitativa de Lokad.

El despliegue exitoso de Lokad (en producción) generalmente produce dos resultados notables: ahorros sustanciales mediante mejores supply chain decisions y ahorros significativos en productividad gracias a decisiones de supply chain (en gran parte) automatizadas.

En términos de gestión del cambio, los ahorros en supply chain generalmente no son 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 en productividad generados por Lokad suelen reinvertirse en otras tareas que aportan mucho más valor añadido 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 eran casi exclusivamente internas: producir un forecast, convertir el forecast en un plan, ajustar los niveles mínimos/máximos de stock en SKUs, componer ó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 son externas: identificar lo que los clientes perciben como calidad de servicio, identificar lo que los proveedores perciben como un obstáculo para bajar 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 manera continua a la solución de Lokad a través del soporte permanente de los SCSs.

Para los ejecutivos de supply chain, el mayor cambio es la eliminación (en gran medida) del constante manejo de crisis. La solución de Lokad ofrece decisiones automatizadas diseñadas para lidiar con casos extremos molestos, reduciendo así sustancialmente el tiempo que los ejecutivos deben dedicar a analizar comportamientos erráticos del mercado. Esto libera a los ejecutivos de supply chain para que puedan planificar estrategias, metas 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 proporcionados por los Supply Chain Scientists (SCSs) de Lokad. Estos expertos no solo gestionan la implementación, sino que también lideran la iniciativa junto con la empresa cliente. Esto incluye muchas tareas, como proporcionar garantías cuantitativas a la dirección de supply chain para demostrar la validez de las recetas numéricas de Lokad antes de su implementación. Los SCSs también proporcionan materiales de capacitación para apoyar la adopción de las prácticas y procesos recomendados por Lokad dentro de la empresa cliente.

Más allá de eso, estos expertos se mantienen 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’.

Consulta las conferencias de Lokad sobre the Supply Chain Scientist y A day in the life of a 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 línea de tiempo de implementación y qué pasos o fases se incluyen en esta línea de tiempo? ¿Cuáles son los objetivos de cada fase (desde el inicio de la implementación del proyecto hasta el Go-Live)?

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 (según se definan en colaboración con el cliente) deberían estar robotizadas. Sin embargo, la automatización suele ser solo un efecto secundario (aunque muy visible) de la verdadera intención: mejorar el desempeño del supply chain. El objetivo de la fase de ‘producción’ es refinar, mejorar y reorientar de manera continua las recetas numéricas, aquellas que permiten la automatización en primer lugar.

Desglose de la línea de tiempo

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

• La primera subfase es la configuración de la data pipeline. El objetivo es crear una pipeline totalmente automatizada para la extracción de datos del cliente hacia Lokad. Los dos aspectos más desafiantes de la data pipeline son establecer la ‘semántica’ de los datos y lograr que el proceso de creación de la pipeline sea (casi) perfectamente fiable. Una data pipeline, a diferencia de una extracción de datos única, es fundamental para mantener relevantes las recomendaciones de supply chain que genera Lokad en relación con las preocupaciones comerciales actuales del cliente.

• La segunda subfase es el diseño de la(s) receta(s) numérica(s) única(s) del cliente, las piezas de lógica de software que impulsan las decisiones de supply chain. El objetivo es lograr recetas que sean consistentes, fiables y sin complicaciones. La redacción de las recetas numéricas iniciales es rápida, generalmente no dura más de una o dos semanas. Sin embargo, estos borradores son solo puntos de partida, y se mejoran rápidamente a través de iteraciones sucesivas por parte del/los Supply Chain Scientist(s) encargado(s) de la cuenta respectiva. Esto elimina rápidamente los molestos casos extremos presentes en los borradores iniciales.

• La tercera subfase es el dual run. La receta numérica ya no produce resultados incoherentes, y se han acordado los impulsores económicos que orientan la optimización. Sin embargo, la receta aún no tiene nivel de producción. Para avanzar, se lleva a cabo un dual run. La receta numérica se ejecuta en paralelo con el proceso heredado. Dado que la receta está automatizada, la sobrecarga organizacional es baja. Cada día, los profesionales de supply chain pueden comparar las decisiones y observar cómo se desarrollan los patrones (por ejemplo, la estacionalidad). A lo largo de varias semanas de dual run, se adquiere la confianza necesaria para continuar 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 se haga cargo del proceso heredado. Esta toma de control también puede hacerse de forma escalonada, dependiendo de la capacidad del cliente para supervisar la gestión del cambio necesaria.

Consulta el resumen de la línea de tiempo para un desglose más detallado de cada paso involucrado en el proceso de optimización.

1.3 ¿Documenta y publica Lokad un plan de gestión del proyecto que detalle el alcance del proyecto, el cronograma/linea de tiempo, los hitos críticos, la asignación de recursos, los entregables, las responsabilidades, el plan de gestión de costos, el plan de gestión de la calidad, el plan de gestión de riesgos y el plan de gestión y comunicación con los interesados?

Sí. Todos esos elementos, y más, se recopilan 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 del ‘por qué’. Los JPM están bien redactados y están diseñados para ser en gran medida accesibles incluso para audiencias menos técnicas y/o no especialistas. El JPM captura la esencia de la intención detrás de la iniciativa y consolida los 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 inútiles, que en la práctica son imposibles de leer (es decir, son tediosos o impenetrablemente técnicos). Dichos documentos no tienen otro propósito que cumplir con casillas arbitrarias. Además, muchos terceros (por ejemplo, integradores, consultores e incluso la burocracia interna) tienen una marcada tendencia a favorecer la cantidad sobre la calidad en lo que respecta a la documentación del proyecto.

En contraste, los JPMs de Lokad están diseñados para ser tanto legibles como leídos. Los JPM son herramientas utilizadas por los propios SCSs para gestionar la iniciativa. Aunque disponemos de pautas extensas sobre lo que se espera encontrar en un JPM, en última instancia depende de los SCSs realizar juicios acertados sobre qué necesita más atención y esfuerzo considerando las particularidades de la iniciativa.

Consulta la conferencia Escribir 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 del proyecto, 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 gestionan 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 a - y de solicitar retroalimentación relevante de - todas las partes involucradas en el lado del cliente del proyecto.

Para una iniciativa particularmente compleja, Lokad instala un comité directivo dedicado compuesto por miembros clave tanto de Lokad como de la empresa cliente. Aunque esta reunión sirve como mecanismo para asegurar la aprobación formal, la mayor parte del trabajo sustantivo ocurre fuera del propio comité. Los SCSs normalmente mantienen interacciones diarias con varios equipos del cliente. Esos equipos se actualizan de manera continua sobre cualquier desviación del plan y se aseguran de que toda la iniciativa se mantenga en curso. Estas interacciones diarias son una forma mucho más eficaz de discutir y superar los problemas técnicos a medida que surgen, en lugar de intentar investigar grandes cantidades de problemas durante una sesión del comité directivo. Por lo tanto, el comité directivo, en sí, actúa como un organismo de supervisión en lugar de un grupo de reflexión para la iniciativa.

Nota: Se sabe que las iniciativas de supply chain cuantitativa frecuentemente se encuentran con “desviaciones positivas”. Estas son sorpresas beneficiosas en la receta que se revelan durante el mantenimiento continuo de la iniciativa. Esencialmente, son oportunidades que son demasiado buenas para dejarlas pasar. Como tal, un beneficio clave del enfoque de comunicación de Lokad es la capacidad de transmitir de manera pronta y eficiente estas desviaciones positivas al cliente tan pronto como surgen, aumentando significativamente el impacto y la agilidad de la iniciativa.

1.5 ¿Documentarán el plan de comunicación, que incluye reuniones diarias, informes de estado semanales de los grupos de trabajo y sesiones de revisión, así como informes y sesiones de revisión mensuales del comité directivo? ¿Establecerán los criterios de escalada y asegurará la mutua concordancia entre la empresa cliente y Lokad en 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 iniciativa.

Lokad participa de buena gana en las reuniones diarias cuando está en el sitio en la sede de la empresa cliente. Sin embargo, por lo general, 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 integral 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 sí aclara los criterios y directrices de escalada, es importante destacar que se espera que un SCS Senior en Lokad maneje cualquier pregunta o inquietud sobre la iniciativa. Así, en lo que respecta a la escalada, la resolución de un problema preocupante se eleva típicamente de un SCS Junior a uno Senior. Esto, históricamente, ha demostrado ser suficiente, con muy pocas situaciones que requieran una escalada adicional.

Lokad considera que todos los problemas –por más insignificantes que parezcan– merecen un análisis en profundidad. Aunque sus efectos son fáciles de resolver, los problemas menores pueden ocasionar dificultades futuras si no se comprenden y abordan las causas raíz. Esto evita que un problema menor se convierta en uno recurrente. Por ello, Lokad prefiere poner a personas altamente capacitadas en primera línea, capaces de abordar tanto el problema inmediato como de identificar las causas subyacentes. Este enfoque es preferible a depender de un personal de soporte no entrenado que continuamente atiende los mismos problemas, un patrón adoptado con demasiada frecuencia por muchos proveedores de software empresarial.

Así, el proceso conciso de escalación de Lokad es intencional, garantizando soluciones rápidas y duraderas.

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

Sí. Más generalmente, 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 exige un compromiso a largo plazo desde el primer día, este aspecto es de menor preocupación – especialmente en comparación con nuestros competidores.

Cabe señalar que nunca hemos observado que una supply chain tenga un desempeño deficiente debido a una ‘falta’ de burocracia y otros procesos frívolos. Por el contrario, las burocracias innecesarias y los procesos insulsos son los problemas más comunes que se encuentran en las supply chain modernas – presentes incluso en empresas que, por lo demás, parecen tener supply chain de alto rendimiento.

1.7 ¿Desplegará un gestor de proyecto dedicado de Lokad que esté basado en la sede de la empresa cliente, acompañado por expertos temáticos en producto, analistas de negocio y expertos en interfaces técnicas?

Sí, si tales disposiciones forman parte de los términos contractuales acordados para la iniciativa. Aunque a Lokad no le opone ubicar empleados onsite en la sede de la empresa cliente, ello incrementa naturalmente el costo de la iniciativa. La mayoría de nuestras iniciativas se llevan a cabo de forma remota, y se apoyan con 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 tener constantemente empleados de Lokad en las oficinas del cliente. Cabe señalar que, aunque Lokad acuerde estacionar un equipo permanente en la sede de la empresa cliente, los empleados rotarán con el tiempo.

Tales 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 continua. Este programa es fundamental para asegurar que nuestros empleados continúen adquiriendo nuevas habilidades o perfeccionando las antiguas, independientemente de su experiencia o antigüedad. Si bien observamos que muchos proveedores de software empresarial permiten que sus empleados operen durante meses, o incluso 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 actuar en una variedad de roles, tales como: experto en la materia, analista de negocio, experto en interfaces técnicas, científico de datos y consultor de supply chain. Estas funciones normalmente serían desempeñadas por varios empleados, lo que resultaría en un aumento significativo del costo para el cliente. En Lokad, cada SCS proporciona todos estos servicios.

Como resultado, los SCSs tienden a ser mucho más productivos (menos personas tiende a significar menos fricción en la comunicación), y también 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 número reducido 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 asigne a un experimentado profesional de supply chain como coordinador de la iniciativa, y que además designe a un ejecutivo de supply chain como supervisor de la iniciativa. El coordinador actúa como el 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 retroalimentación. 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 principal SCS 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.

Es necesario asignar algunos recursos de TI para la configuración del pipeline de datos al inicio de la iniciativa. Lokad es más eficiente que la mayoría de sus pares en este sentido. Por ejemplo, extraemos de manera automática y directa los datos transaccionales del cliente, sin requerir ninguna limpieza o preparación por parte del mismo. A menos que la empresa cliente esté experimentando vendor lock-in, esta configuración técnica requiere menos de 4 semanas de trabajo para un único colaborador – y a veces mucho menos cuando ya existe un data lake.

Luego, los SCSs deberán recopilar percepciones cualitativas sobre los procesos existentes, y los detalles de todas las prioridades y restricciones de la supply chain. Generalmente se llevarán a cabo una serie de entrevistas, facilitadas por los coordinadores, 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 dichas recetas y permitir que los SCSs las refinen y mejoren.

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 debido a la indecisión. Por ejemplo, Lokad puede proponer diversas opciones para modelar los costos asociados a 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 es necesario 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 a los objetivos específicos de la empresa cliente.

Para más información, Lokad dispone de varias conferencias dedicadas a la ejecución táctica y estratégica de una exitosa optimización de supply chain.

2. Gestión de Recursos y Requisitos

2.1 ¿Cuáles son los requisitos de mano de obra para la implementación del proyecto en la empresa cliente, específicamente el número de recursos y su nivel de experiencia? ¿Puede definir con precisión el número de recursos para cada fase y subfase del proyecto?

Una iniciativa típica de Lokad requiere aproximadamente de 0.5 a 2 FTE (empleados a tiempo completo equivalentes) de la empresa cliente durante los primeros 6 meses – es decir, la fase de onboarding. Una vez que la iniciativa entre en producción, se estima razonablemente que el proyecto seguirá requiriendo al menos 0.25 FTE. Naturalmente, estas estimaciones varían sustancialmente según el tamaño y la complejidad de la empresa cliente y sus necesidades específicas de supply chain.

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

• Meses 1 y 2: La configuración del pipeline de datos requiere 4 semanas de esfuerzo a tiempo completo por parte de un data officer, normalmente empleado por el departamento de TI del cliente. El data officer debe estar bastante familiarizado con el panorama aplicativo de la empresa cliente. Este requisito puede disminuirse si ya existe un data lake, pero, por el contrario, se incrementará si el pipeline de datos tiene que gestionar múltiples sistemas de negocio (p.ej., 1 ERP por país). Una vez en funcionamiento, su mantenimiento no debería requerir más que unas pocas horas al mes por parte del data officer.

• Meses 3 y 4: El diseño de la receta numérica requiere 2 o 3 días por semana por parte del coordinador (cliente) de la iniciativa, un mínimo de 10 horas semanales de varios profesionales de supply chain para proporcionar perspectivas de alto nivel, y posteriormente para dar retroalimentación sobre las cifras producidas por Lokad. Se espera que el coordinador esté familiarizado con la empresa y su supply chain, y que maneje bien el trabajo analítico. Sin embargo, este puesto no requiere habilidades especializadas en TI ni conocimientos específicos de data science. La revisión semanal de la iniciativa requiere medio día a la semana de un ejecutivo de supply chain.

• Meses 5 y 6: Los requisitos son esencialmente los mismos que en la fase anterior, sin embargo, el enfoque cambia. Ahora, el coordinador dedica la mayor parte de su tiempo a preparar el lanzamiento adecuado y a comunicarse con todos los profesionales de supply chain afectados. De igual forma, el ejecutivo de supply chain supervisa la gestión interna del cambio relacionado con los nuevos procesos que surgen de la iniciativa de Lokad.

Consulte también Implementación y Gestión del Proyecto 1.2.

2.2 ¿Se asegura de que se planifique una mano de obra adecuada para apoyar la transición del producto?

Sí. Como regla general, Lokad recomienda mantener la misma cantidad de recursos (p.ej., 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. Es un error abordar la resolución de tales desafíos con una mentalidad de “configurar y olvidar”, ya que cualquier solución técnica inevitablemente – y de forma continua – derivará hacia la irrelevancia y la obsolescencia si no se monitorea y mantiene adecuadamente.

Cabe destacar que, dado que Lokad automatiza las decisiones de supply chain, no existe una urgencia estricta en reentrenar a todos los profesionales de supply chain del cliente con un nuevo proceso para mantener en funcionamiento la supply chain; la automatización está diseñada para encargarse de ello. Como resultado, no es inusual que la revisión completa de la organización de supply chain del cliente – desencadenada por la iniciativa de Lokad – se complete apenas meses después de que el proyecto se haga operativo.

Este enfoque simplificado contrasta marcadamente con las grandes y costosas “fuerzas de tarea” que a menudo requieren los proveedores de software empresarial para poner en marcha el proyecto.

2.3 ¿Puede garantizar que habrá disponibilidad de suficiente mano de obra y recursos de producto de conocimiento (KP) en la sede de la empresa cliente para apoyar la transición del producto?

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

Consulte también Implementación y Gestión del Proyecto 1.7.

Consulte también Gestión de Recursos y Requisitos 2.2.

2.4 ¿Organiza sesiones de revisión de requisitos con los propietarios de productos de negocio para identificar y documentar los requisitos?

Sí. Uno de los primeros objetivos del Supply Chain Scientist es adquirir todas las percepciones necesarias sobre la supply chain del cliente. Este proceso se lleva a cabo típicamente a través de entrevistas con las partes interesadas relevantes, incluidos los propietarios de productos de negocio. También tratamos de revisar detenidamente la documentación existente (cuando está disponible), para aprovechar al máximo esas entrevistas.

Sin embargo, la principal preocupación de Lokad es entender el ‘problema’ que se investiga, lo cual no siempre se facilita al enumerar ‘requisitos’. Por ejemplo, si un cliente menciona que requiere un tratamiento especial para los ‘slow movers’, entendemos que el bajo volumen es una preocupación a abordar. No obstante, tratar de manera especial esos SKUs 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, tras investigar los puntos críticos de la supply chain del cliente, puede resultar que los ‘slow movers’ sean SKUs que han sido mal valorados, agrupados y/o asignados. Una vez que se comprende mejor el problema (los slow movers), la estrategia de intervención cambia por completo – a menudo facilitando su abordaje.

Por lo tanto, aunque Lokad identifica y documenta todos los requisitos del cliente, nuestro enfoque enfatiza el descubrimiento de la verdadera naturaleza del problema, en lugar de aceptar tal como es el estado actual de la supply chain del cliente.

Vea Enamórate del problema, no de la solución para obtener más información sobre la dicotomía problema-solución.

2.5 ¿Proporciona estimaciones para el esfuerzo, los costos y los cronogramas de funciones que requieren personalización, incluidas las interfaces del sistema, y las comparte después del taller de análisis de brechas de ajuste del proceso?

Sí. Estas estimaciones se incluyen típicamente en nuestra propuesta comercial inicial. Si se organiza un taller para preparar la iniciativa, utilizaremos la información del mismo para refinar aún más nuestra propuesta.

La plataforma de Lokad es programática. Así, la implementación está diseñada para ser soportada por scripts, escritos en Envision, nuestro DSL (lenguaje de programación específico del dominio) dedicado a la optimización predictiva de supply chains. Como resultado, Lokad está especialmente capacitado para ofrecer funciones e interfaces hechas a la medida, ya sea que estas interfaces estén destinadas a personas o a los sistemas de negocio de la empresa cliente.

A diferencia de la mayoría del software empresarial, la programabilidad es una característica principal en Lokad. Los scripts de Envision mencionados no son una ‘personalización’ de la solución de Lokad en el sentido habitual. Tampoco la presencia de esos scripts supone una desviación de la rama principal de desarrollo de la solución de Lokad. Más bien, la rica programabilidad de Lokad es el camino de implementación previsto.

Como resultado, existe un grado de certeza sumamente alto asociado 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.

Consulte Estudio de Caso sobre el Desastre SAP de 500 Millones de € de Lidl para obtener más información sobre este punto.

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

Sí. Conservamos a los empleados durante un promedio de 3.5 años, lo cual es casi el doble de la permanencia comparado con cohortes similares (ingenieros talentosos en IT, o dominios adyacentes a IT) en mercados similares (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 inversión continua de Lokad en la capacitación de sus equipos. En particular, el contenido de supply chain publicado por Lokad en su propio sitio web, en especial nuestra serie de conferencias de supply chain, puede verse como un subproducto del enfoque de Lokad en capacitar a su propio personal. Generalmente, los proveedores de software empresarial que no cuentan con materiales de capacitación públicos casi nunca tienen materiales de capacitación privados tampoco (incluso si invariablemente afirman lo contrario).

En términos de planes de sucesión, contamos con dos prácticas importantes. Primero, cada iniciativa de Lokad viene acompañada de un Manual de Procedimientos Conjunto (JPM). El JPM es el documento principal que utiliza un nuevo SCS para familiarizarse rápidamente con todos los conocimientos y tecnicidades relevantes de la iniciativa. Segundo, cada iniciativa cuenta – en todo momento – con un SCS principal y uno secundario. Aunque el SCS secundario no contribuya directamente a la iniciativa, Lokad destina el tiempo suficiente para asegurarse de que esta persona esté lista para asumir la iniciativa en caso de que surja la necesidad. Esta práctica mitiga en gran medida las complicaciones relacionadas con ausencias/rotaciones no planificadas.

3. Roles, Responsabilidades y Gestión de Interesados

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 más alto 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 tanto la colaboración tiende a ser más fuerte en aquellas donde el supply chain es el pilar (reconocido) de sus actividades.

El término ‘partner’ se ha diluido hasta el punto que incluso los proveedores de productos de software triviales (como el software de seguimiento de tiempo) terminan siendo referidos como ‘partner’. Sin embargo, después de uno o dos años, la mayoría de nuestros clientes sí se refieren a su relación con Lokad como una asociación ‘genuina’ – en el verdadero sentido de la palabra. Tienen caras conocidas en Lokad que se han ganado su confianza y, en consecuencia, esas personas – típicamente Supply Chain Scientists (SCSs) – conocen íntimamente 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 de la empresa, incluso en compañías grandes.

La colaboración continua con Lokad permite a nuestros clientes reestructurar 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 destacar 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/los aspecto(s) más mundano(s) y repetitivo(s) de los procesos de toma de decisiones de supply chain. Este enfoque, posteriormente, libera recursos del cliente significativos – y a menudo escasos – que pueden ser redirigidos a usos mejores.

3.2 ¿Qué roles y responsabilidades espera que estén presentes, tanto dentro de 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 participación de la alta dirección en la iniciativa de supply chain cuantitativa. Aunque no se espera que se adentre en los detalles técnicos, esta persona debe entender y comunicar los conocimientos estratégicos de la iniciativa. Su rol no es crear métricas y KPIs, sino evaluarlas y cuestionarlas críticamente, 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 un puente entre varios equipos internos. Su responsabilidad principal es recopilar retroalimentación, comunicarse con las partes interesadas y confirmar/aclarar procesos y decisiones. Se asegura de que la iniciativa se alinee con los flujos de trabajo existentes de la empresa, al mismo tiempo que se mantiene abierta a la posibilidad de revisar dichos flujos en el futuro.

• The Data Officer: Los datos son la columna vertebral de la iniciativa de supply chain cuantitativa, y esta persona asegura su accesibilidad y fiabilidad. Encargada 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 es crucial para su éxito.

• The Supply Chain Scientist: Este rol fusiona los conocimientos del Supply Chain Coordinator con los datos del Data Officer para automatizar los procesos de toma de decisiones. Comenzando con la preparación de 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 cantidades de reorden, e implementa dashboards y KPIs para garantizar la transparencia y el control.

Consulta project roles para 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 ser presentada explícitamente como una tabla RACI si la empresa cliente lo considera importante.

Más importante aún, los Supply Chain Scientists (SCSs) internalizan este tipo de matriz para tomar decisiones de juicio adecuadas y rápidas a medida que avanza la iniciativa. En lo que respecta a cuestiones relacionadas con la optimización de un supply chain, la clave es encontrar la mejor manera de enmarcar el problema. A continuación, el enfoque se desplaza hacia identificar quién dentro de la organización es el mejor posicionado para abordar el problema. Es fundamental que todo este análisis se realice rápidamente para mantener el impulso de la iniciativa.

Con este fin, los SCSs de Lokad son designados para liderar la iniciativa y asumir la responsabilidad sobre la calidad del resultado generado por la receta numérica de Lokad.

Como tal, se trata de un pequeño núcleo de especialistas altamente capacitados quienes son responsables de las decisiones de supply chain que genera Lokad, en lugar de un “sistema” o “proceso” elaborado de delegar porciones de responsabilidad entre un gran grupo de partes interesadas. La postura de Lokad es que tales sistemas tienden a diluir la responsabilidad, en lugar de rigidecerla. Por ello, nuestros SCSs son entrenados para adoptar y operar con esta responsabilidad, lo que incluye asegurar que las partes interesadas relevantes en la empresa cliente sean consultadas e informadas completamente sobre la iniciativa.

3.4 ¿Documentará los roles y responsabilidades utilizando una matriz RACI (Responsibility, Accountability, Consulted, and Informed) para todas las partes interesadas involucradas 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 recopilan y documentan en el Manual de Procedimientos Conjunto (JPM). El JPM es producido por los Supply Chain Scientists (SCSs) de Lokad (con conocimientos recolectados 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 escrito 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 del cliente y la solución integral (sin simplemente regurgitar la literatura preexistente del cliente).

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

En una nota relacionada, nuestra experiencia indica que, en caso de que surjan desacuerdos, generalmente reflejan un problema organizacional 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 ¿Garantizará que el grupo de trabajo del proyecto y los grupos directivos se conformen con recursos identificados de las partes interesadas del proyecto? ¿Se asegurará de que el ritmo operativo sea acordado por todas las partes involucradas?

Sí. Como principio general, seguimos cualquier proceso que sea considerado necesario por – y formalmente acordado con – la empresa cliente. Los elementos acordados (y cualquier cambio realizado a medida que avanza la iniciativa) se documentan en el Manual de Procedimientos Conjunto (JPM), el cual incluye detalles sobre el 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 manera anecdótica, 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. Transición del Sistema y Puesta en Marcha

4.1 ¿Cuál es la duración de la transición desde el inicio hasta la puesta en marcha?

La duración típica de la fase de incorporación es de 6 meses. Esta fase comienza con el kick-off y termina cuando Lokad está ‘en producción’ – es decir, nuestras recomendaciones automatizadas de supply chain dirigen efectivamente el proceso de toma de decisiones deseado por el cliente.

Esta duración puede reducirse por 1 mes si ya existe un data lake – un data lake bien construido y documentado puede acortar aún más la fase de incorporación. Por el contrario, esta fase suele incrementarse entre 1 y 3 meses cuando el entorno de software o sistemas del cliente es excesivamente complejo o está desactualizado.

Curiosamente, la complejidad del supply chain en sí misma no tiene tanto impacto como podría parecer, ya que Lokad se esfuerza por definir un alcance lo suficientemente preciso para que sea factible dentro del plazo previsto. Nuestra experiencia indica que las fases de incorporación que duran más de 6 meses ponen en riesgo la iniciativa al provocar estancamiento. Por lo tanto, diseñamos activamente el alcance para mitigar este riesgo.

Tales demoras tienen poco que ver con la configuración técnica de Lokad en sí. En conjunto, la línea de tiempo sugerida sirve no solo para propósitos técnicos (automatizar la extracción de datos, probar recetas numéricas, etc.), sino también para que los Supply Chain Scientists (SCSs) de Lokad se familiaricen completamente con todas las particularidades de la empresa cliente, y para que los equipos de supply chain “asimilen” el enfoque de Lokad – algo que típicamente representa un alejamiento del proceso heredado del cliente.

4.2 ¿Cuántas visitas in situ planea? ¿Cuántos talleres in situ planea?

El número de visitas y talleres realizados in situ 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 cobra Lokad. Por lo tanto, la inclusión de visitas in situ 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 ligera posible, nos conformamos con una iniciativa totalmente remota, es decir, sin visitas in situ. Recomendamos este enfoque para empresas más pequeñas (ingresos anuales inferiores a 100M USD) y para aquellas que generalmente se sienten cómodas con colaboradores remotos (como grandes ecommerce companies). Aproximadamente la mitad de las iniciativas llevadas a cabo por Lokad pertenecen a esta categoría.

Cuando el objetivo de la empresa cliente es maximizar las probabilidades de gestionar el cambio con éxito, aceptamos visitas cada mes – y posiblemente con mayor frecuencia si es necesario. Para las empresas grandes (ingresos anuales superiores a 1B USD), recomendamos al menos una visita/taller in situ trimestral. Este enfoque ayuda a desarrollar una alineación en toda la empresa, especialmente cuando se involucran equipos de gran tamaño.

Para nuestros clientes en Europa Occidental, tendemos a tener más visitas (que generalmente duran un solo día) que talleres cuando estamos in situ. Para nuestros clientes fuera de Europa Occidental, solemos realizar más talleres (que generalmente duran varios días) que visitas cuando estamos in situ. Esta diferencia es simplemente una cuestión de costos de viaje y logística asociados.

4.3 ¿Cuál es el equilibrio ideal entre reuniones remotas e in situ?

Para una iniciativa de supply chain cuantitativa, 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 informática, incluyendo el acceso a monitores grandes. Esto es especialmente útil cuando los participantes necesitan investigar informes complejos.

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

Este enfoque permite a ambas partes mantener las reuniones remotas como algo discreto, 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 la puesta en marcha, incluida 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 la puesta en marcha. 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) genere los resultados, sigue siendo una persona quien asume la responsabilidad personal del sistema. Esta persona asegura la precisión, relevancia y adecuación de la cadena de procesamiento de datos de extremo a extremo – teniendo también en cuenta las preocupaciones comerciales generales del cliente.

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

Por favor, consulte programming paradigms for supply chain para comprender mejor el tipo de tecnologías que Lokad utiliza para garantizar 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 inconvenientes de las operaciones comerciales (desde la aplicación de negocio existente hasta la nueva aplicación de negocio) para la empresa cliente?

Sí. La transición se documenta en nuestro Joint Procedure Manual (JPM). Esta extensa documentación, producida por los Supply Chain Scientists (SCSs) de Lokad, asegura que tanto los supply chain practitioners como los supply chain executives tengan acceso a materiales bien redactados que expliquen adecuadamente el proceso en términos comprensibles. Los SCSs hacen 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 sin sobresaltos del proceso legado 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 legado a lo largo de todo el alcance de la iniciativa. La práctica es posible únicamente debido a la naturaleza robotizada del proceso de toma de decisiones legado por parte de Lokad, lo que garantiza que las recetas numéricas implementadas por los SCSs de Lokad hayan estado funcionando satisfactoriamente en condiciones de producción exactas, durante todo el alcance, durante semanas previas al go-live real, donde las decisiones de Lokad reemplazan al proceso legado.

Cabe señalar que dicho dual-run típicamente no es posible con las tecnologías y metodologías alternativas propuestas por nuestros competidores. De hecho, dado que ellos no robotizan las decisiones de supply chain, los costos generales asociados con un dual-run son significativos. Como resultado, el dual-run se efectúa, en el mejor de los casos, sobre un alcance pequeño que no refleja verdaderamente las condiciones de producción. En consecuencia, cuando se adopta tal enfoque, la extensión tardía del alcance invariablemente conduce a incidentes de producción que habrían sido completamente evitables con un dual-run de alcance completo.

4.6 ¿Proporciona el alcance, los plazos y los criterios de éxito para la ejecución piloto, para ser revisados y aprobados por la empresa cliente?

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

El plazo suele ser inferior a 6 meses (desde el kick-off hasta la producción). Aunque siempre se incluye un plazo proyectado en nuestra propuesta comercial, puede que no se especifique en el acuerdo contractual. El plazo 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 empresa cliente, en particular la construcción de una data pipeline hacia Lokad.

En cuanto a los criterios de éxito, la decisión siempre la toma de manera unilateral la empresa cliente. Aunque podemos documentar los principios rectores 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 la empresa cliente opina lo contrario.

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

Consulte Assessing the Success of a Quantitative Supply Chain Initiative para saber más sobre este punto matizado.

4.7 ¿Organiza la realización de ejecuciones 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 ofrecer supply chain optimization – 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 que ha sido aprobada para uso en producción.

El equipo de Supply Chain Scientists (SCSs) de Lokad es responsable de todo lo anterior. En nuestra experiencia, la adecuación de los datos rara vez es un problema en las empresas que se digitalizaron hace muchos años (si no décadas) atrás. Mientras exista un sistema de negocio para rastrear lo que se compra, produce, almacena y vende, la iniciativa casi garantiza tener datos adecuados. El desafío consiste en darle sentido a los datos que originalmente no fueron recogidos para apoyar la optimización de supply chain.

Véase bad data para obtener más información sobre este punto.

5. Gestión del Cambio y Riesgos

5.1 ¿Qué apoyo puede ofrecer a la empresa 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, todos ellos capacitados para manejar los requerimientos técnicos y no técnicos de una iniciativa de supply chain optimization. Los SCSs asisten en el proceso de gestión del cambio de diversas maneras, incluyendo:

• Proponer mejoras a los procesos existentes para los supply chain practitioners empleados por la empresa cliente.

• Producir materiales de formación para integrar a los miembros/equipos de la empresa 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 introducidos en supply chain.

Cabe señalar que la gestión del cambio puede representar un compromiso de tiempo significativo para un SCS. Aunque cada SCS tiene habilidades y experiencia únicas y adecuadas para ayudar al liderazgo de supply chain en la gestión del cambio, esta tarea compite con todas sus otras 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án disponibles para apoyar la iniciativa. Nuestras propuestas comerciales suelen prever que los SCSs proporcionarán cierto apoyo en la gestión del cambio. Sin embargo, nuestras propuestas normalmente 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 su visión para la gestión del cambio? ¿Cuáles son los principales hitos? ¿Cómo es la nueva organización tras la implementación exitosa de la nueva solución?

Una vez que Lokad está en producción, toda una categoría de supply chain decisions queda automatizada. El objetivo es entonces convertir la práctica de supply chain en una empresa capitalista. Cada hora que un supply chain practitioner dedica debería contribuir a la mejora continua de las recetas numéricas. Esto supone una desviación de la práctica de supply chain ‘mainstream’, en la que la gran mayoría de los esfuerzos en cualquier día se destinan a mantener a la empresa en funcionamiento por un día más. Naturalmente, la transición a esta forma de supply chain que aporta valor es gradual.

• El primer hito es lograr que los supply chain practitioners reconozcan que Lokad les permite descartar la mayor parte del proceso legado. Por ejemplo, tiene sentido revisar las cantidades de reposición diarias cuando esas cantidades son frecuentemente incorrectas. Sin embargo, por diseño, las cantidades de Lokad ya son sólidas y no requieren revisión adicional. De hecho, un 0% de inconsistencias en las cifras generadas por Lokad es el criterio principal para un go-live en producción. La confianza que los supply chain practitioners pueden depositar en las cifras de Lokad naturalmente libera mucho tiempo que puede ser aprovechado de mejor manera.

• El segundo hito consiste en contar con algunos “early adopters” entre los supply chain practitioners. Se trata, por lo general, de personas que logran separarse rápidamente del proceso legado que no aporta valor — por ejemplo, revisar manualmente las cifras — para concentrarse en la mejora continua de supply chain a través de sus recetas numéricas. Pueden comenzar a abordar numerosas cuestiones importantes más allá de simples aspectos técnicos menores (por ejemplo, ¿está la empresa cliente evaluando su calidad de servicio desde la perspectiva adecuada?).

• El tercer hito es lograr que la mayoría de los supply chain practitioners miren hacia el exterior (clientes y proveedores) en lugar de hacia el interior. En última instancia, supply chain debe ofrecer un alineamiento que trascienda los límites de la empresa cliente. Esto amplía el conjunto de insights recogidos 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 gestionen manualmente, ya que las tareas repetitivas ahora están automatizadas. También existen muchas menos emergencias (nuevamente, debido a la automatización). La reducción de tareas rutinarias conlleva un aumento en la variedad de tareas para el supply chain practitioner. Típicamente, esto se traduce en menos tiempo y esfuerzo dedicados a controlar supply chain, pero se espera más de la dirección para mejorar las habilidades de los empleados y que puedan capitalizar el mayor tiempo y esfuerzo disponible.

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

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

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

Sin embargo, si el cliente lo solicita explícitamente, Lokad es capaz de introducir un “workflow” que refleje el legado. Esto, cabe entender, es puramente para facilitar la gestión del cambio, y no es un requisito para el éxito de la receta numérica de ninguna manera. A medida que los empleados del cliente se familiaricen más y desarrollen mayor confianza en las decisiones que genera Lokad, el “workflow” puede simplificarse gradualmente, hasta el punto de eliminarlo por completo.

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

5.4 ¿Puede mantener un registro de Issues & Risk que incluya un plan de mitigación, tareas, responsabilidades, plazos y estado (no iniciado, en progreso, cerrado, en espera)? ¿Será el Project Manager de Lokad responsable de rastrear todos los Issues & Risks y de asegurar resoluciones oportunas o gestionar las escaladas cuando sea necesario?

Sí. La plataforma de Lokad incluye un gestor interno de issues/tickets/tareas. Esta función ofrece todas las capacidades habituales que se esperan comúnmente de esta herramienta, tales como gestionar estados, prioridades, asignaciones, notificaciones, etc. Además, mantenemos por separado un Joint Procedure Manual (JPM) que proporciona una presentación integral y bien organizada de la iniciativa con todos los plazos de alto nivel relevantes. Los Supply Chain Scientists (SCSs) de Lokad son responsables de la supervisión del gestor de tareas. Se aseguran de que los issues y las inquietudes se atiendan de manera inmediata.

Las escaladas son posibles, pero raras. El mismo SCS que gestiona/revisa las tareas también las resolverá. Los Senior SCSs en Lokad desempeñan una amplia gama de roles: supply chain expert, 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 aspecto muy positivo. El cliente puede interactuar de inmediato con la persona cuya función es supervisar la resolución satisfactoria de cualquier issue, en lugar de tener que navegar por 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 ¿Ofrece consultoría de gestión del cambio organizacional para abordar la introducción y modificación de procesos de negocio, así como la desmantelación de procesos existentes?

Sí, si la empresa 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 reside en la predictive optimization of supply chain y no en la gestión del cambio. Nuestro enfoque hacia la gestión del cambio también es más convencional que nuestras prácticas de supply chain. Este enfoque, si se implementa, limitaría la cantidad de terceros involucrados en el proyecto.

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

6. Personalización y Funcionalidad del Sistema

6.1 ¿Organiza 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 el lanzamiento de personalizaciones?

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

Esto mejora en gran medida la calidad de la priorización, ya que la empresa cliente se beneficia de un experto que puede equilibrar fácilmente los beneficios de cualquier supply chain change con los costos asociados a dicho cambio.

Segundo, ‘Supply Chain Quantitativa’ – la filosofía general de Lokad – enfatiza una perspectiva puramente financiera. Así, el SCS apoya a la empresa cliente en proporcionar estimaciones cuantitativas (en dólares o euros) del impacto de un cambio potencial a implementar en la solución. Esta estrategia refina la iniciativa evitando el tradicional cuello de botella de debatir qué se debe priorizar. En su lugar, Lokad agiliza este proceso priorizando los asuntos que generan el mayor impacto financiero.

6.2 ¿Pueden realizar un estudio fit-gap de todos los procesos empresariales 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 identifiquen brechas en la funcionalidad del producto?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Si bien se realizará un estudio inicial al comienzo de la iniciativa, este proceso continúa durante toda 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 del supply chain, las brechas rara vez se deben a ‘funcionalidad’, sino más bien a ‘rendimiento’. Por ejemplo, el desafío no es solo generar cantidades de reposición (funcionalidad) sino garantizar que las cantidades generadas sean las más rentables (rendimiento).

Así, los SCSs se encargan de identificar y abordar ‘brechas de rendimiento’, que a veces requieren funcionalidad adicional o la 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 ser abordada introduciendo (o ajustando) unas pocas líneas de Envision code. Esta programabilidad es precisamente lo que permite a Lokad proporcionar soluciones hechas a la medida a cada cliente.

6.3 ¿Pueden proporcionar una agenda detallada para los talleres de análisis fit-gap del proceso, incluyendo las expectativas del SME (Experto en la materia) por parte del cliente, al menos una semana antes de comenzar 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 empresa cliente da instrucciones explícitas, como un plazo para proporcionar la(s) agenda(s), las seguiremos. En ausencia de instrucciones, estructuraremos los talleres (incluyendo el cronograma y comunicando todos los pasos necesarios del lado del cliente) de manera inteligente y profesional.

6.4 ¿Se asegura de que los documentos de requisitos de personalización del producto sean revisados y aprobados conjuntamente por la empresa cliente?

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

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

Así, las soluciones de Lokad están siempre ‘personalizadas’ en el sentido de que están completamente hechas a la medida de las necesidades específicas de la empresa cliente. Sin embargo, dicha personalización se entrega de una manera 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 las interfaces con sistemas externos, y en probar y certificar las interfaces?

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

Las interfaces del sistema generalmente no son ‘certificadas’ por un organismo de certificación independiente. Las interfaces se ‘especifican formalmente’ a través de 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; y Lokad, a su vez, se compromete a devolver los resultados puntualmente.

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 pueden incluirse si la empresa cliente lo desea.

Sin embargo, dada la naturaleza del servicio de Lokad, es muy probable que los “mensajes de ejemplo” adopten la forma de tablas, ya que esto representa de manera más precisa el resultado que Lokad genera para el cliente. Como referencia, la gran mayoría de las especificaciones técnicas de las interfaces se centrarán en las tablas y sus formatos, así como en los patrones de extracción de tablas y los cronogramas de transferencia.

6.7 ¿Comparten los procesos de gestión de solicitudes de cambio y liberación?

Sí. Los Supply Chain Scientists (SCSs) de Lokad están a cargo de este proceso. Es importante señalar que Lokad cuenta con dos niveles de cambios y liberaciones, lo cual es diferente al 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, especialmente durante la fase de incorporación. Dichos cambios son una respuesta directa a las necesidades de la empresa cliente e implican una comunicación considerable entre ambas partes.

En segundo lugar, realizamos actualizaciones a la plataforma de Lokad, generalmente a través de actualizaciones a Envision – nuestro DSL (lenguaje de programación específico del dominio) dedicado a la optimización predictiva del supply chain. Estos cambios están diseñados para ser transparentes para las empresas cliente. Si se desea, se pueden proporcionar 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 configurar el entorno de pruebas 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 ítems se clasifican en orden decreciente de retorno de inversión (ROI) para la empresa. Este aspecto es crítico para garantizar que el tiempo de los usuarios finales no se desperdicie revisando grandes cantidades de datos en gran parte 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-inquilino, y por lo tanto pueden introducirse con un sobrecoste mínimo, tanto en términos de recursos de cómputo como de tiempo de administración del sistema.

Véase también User Acceptance Testing 7.3.

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

Sí. Dada la rica programabilidad de la plataforma de Lokad, podemos ejercer un control total sobre las configuraciones. Esto es posible gracias a Envision – nuestro DSL (lenguaje de programación específico del 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, que 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 capacitación para el producto (incluidas las interfaces requeridas) a la empresa cliente y 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-inquilino, y por lo tanto pueden introducirse con un sobrecoste mínimo, tanto en términos de recursos de cómputo 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 garantiza 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 eluden todo el asunto 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 linealmente 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 acordados mutuamente?

Sí, siempre que 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 la inversión. En un escenario típico, el SCS propone una acción adecuada y un cronograma correspondiente, que la empresa cliente valida o actualiza a su discreción.

Es fundamental destacar que, en lo que respecta al supply chain, no existen soluciones perfectas, solo compensaciones mejores y peores. En otras palabras, no se puede realmente resolver un problema donde dos o más valores están en completa oposición.

Por ejemplo, el inventario perecible caducado es un desperdicio, pero al manejar productos perecibles, tal desperdicio no puede eliminarse completamente sin crear un consecuente problema de calidad de servicio. Es necesario 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 corregir un error de análisis al leer un archivo (un error de software). Sin embargo, el objetivo general de una solución de supply chain cuantitativa no es “resolver problemas”, sino aumentar el retorno de la inversión (en dólares o euros). Lokad logra esta forma de “resolución” mediante un enfoque inteligente y financieramente impulsado a las compensaciones del supply chain.

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

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 del 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 de supply chain de extremo a extremo. Este requisito no tiene nada que ver con Lokad; es simplemente la naturaleza del 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 de manera individualizada por cliente.

Cabe señalar que una iniciativa de supply chain cuantitativa con Lokad presenta una mejora continua del supply chain, por lo que no existe un período fijo de UAT. Las pruebas suelen comenzar al final del segundo mes, alcanzar su punto máximo en el cuarto mes y luego estabilizarse a partir del sexto mes.

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

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

8. Soporte y Auditoría Post-Implementación

8.1 ¿Pueden asegurar que las observaciones de las ejecuciones piloto se documenten, y que cualquier acción a tomar se asigne a los interesados pertinentes en los departamentos Técnico, TI y de Proveedores de la empresa cliente, y que además se realice un 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 percepciones pertinentes para la iniciativa. Es importante destacar que el JPM está diseñado para ser accesible a audiencias no técnicas (aunque algunas secciones y anexos son bastante técnicos).

Las acciones de alto nivel se documentan en el JPM. Sin embargo, las acciones menores suelen gestionarse con el gestor de tareas en la plataforma de Lokad. Estos ítems menores son de corta duración y el gestor de tareas facilita su seguimiento y cierre mejor que el JPM.

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

Sí. Los Supply Chain Scientists (SCSs) de Lokad suelen implementar 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 el supply chain. Esto se hace para identificar posibles fuentes de divergencia, como errores o fallos en los sistemas del 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 para mejorar el uso y la adopción del sistema por parte del usuario final, a fin de lograr el retorno de la inversión (ROI) 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 la solución en su totalidad varias veces a lo largo del año. La auditoría anual generalmente conduce a una presentación de hoja de ruta detallada para el liderazgo del cliente. Esto está en línea con nuestro enfoque de continuous improvement para cada iniciativa.

Respecto al uso, en la práctica, los SCSs implementan de manera proactiva herramientas dedicadas desde el principio para monitorizar el uso, la adopción y el cumplimiento de las decisiones de supply chain que genera Lokad. Aunque una auditoría anual presenta una excelente oportunidad para realizar los ajustes necesarios, nuestros SCSs son muy proactivos en lo que se refiere 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 ¿Puede asegurar que el equipo de soporte al producto dedicado, ubicado en la sede central de la empresa cliente, continúe apoyando el producto durante al menos 6 meses post go-live?

Sí. El equipo de Supply Chain Scientists (SCSs) de Lokad se encarga de esta tarea. Nuestros SCSs están ampliamente capacitados para tanto mejorar continuamente la iniciativa como para brindar soporte continuo al cliente. La presencia continua in situ de los SCSs se negociará y especificará en el acuerdo contractual con el cliente, si es algo que éste 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 cese de los esfuerzos de mejora continua, según nuestra experiencia, socava la fortaleza de la iniciativa. Cualquier cambio del lado del cliente, incluidos ajustes modestos en el paisaje aplicativo o restricciones, puede impactar la calidad de las decisiones de supply chain que genera Lokad, por lo que se recomienda una vigilancia activa y una mejora continua.

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

9. Incident & Defect Management

9.1 ¿Puede asegurar que todos los defectos imprescindibles y solicitudes de cambio (elementos críticos y de alta prioridad) se atiendan como prioridad y se entreguen, para evitar cualquier retraso en el cronograma de go-live 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 ágil 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 programabilidad significa que los SCSs pueden entregar rápidamente correcciones e implementar los cambios solicitados en la iniciativa, alcanzando un nivel de precisión que no es común en el software empresarial.

Más allá de la tecnología, los SCSs de Lokad están capacitados para desempeñar una serie de roles clave, lo cual reduce de manera natural el número de personas necesarias para abordar defectos y solicitudes de cambio. Estos roles incluyen supply chain expert, business analyst, data scientist, data engineer y system integrator. Están, por lo tanto, bien entrenados para proporcionar correcciones y actualizaciones, sin dejar de tener en cuenta las principales prioridades del cliente.

Véase también Customization & System Functionality 6.2.

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

Sí, la plataforma de Lokad cuenta con su propio sistema de gestión de tareas/tickets/incidencias. Esas capacidades nos proporcionan la capacidad de seguir con precisión la resolución oportuna de los problemas. Dichas resoluciones son atendidas por los equipos de Supply Chain Scientists (SCSs) empleados por Lokad.

Sin embargo, es importante no agrupar los “defects” y los “usability issues”. Por ejemplo, un inaccurate demand forecast es un “defect”. Está impactando negativamente la supply chain. Sin embargo, dependiendo de las condiciones del mercado en las que opera la empresa cliente, este “defect” puede que nunca se corrija, sino solo se mitigue. En lo que respecta a la optimización predictiva de supply chains, las soluciones siempre implican un trade-off: al resolver un defect, se crea otro (esperemos que más pequeño).

En contraste, los usability issues suelen ser sencillos de abordar. Por ello, para esta clase de problemas, estamos dispuestos y comprometidos a garantizar una resolución oportuna, ya que resolver el problema no suele generar otro.

9.3 ¿Puede asegurar 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 go-live de la empresa cliente?

Sí. Si los defectos identificados conciernen al código específico del cliente (escrito en Envision), entonces serán rectificados por los Supply Chain Scientists (SCSs) de Lokad. Si los defectos identificados conciernen a la plataforma de Lokad, 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 (go-live).

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

Los Supply Chain Scientists (SCSs) tratan todos los informes de incidentes - independientemente de cómo se originen - 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 semanales en las que el cliente puede esperar que esté disponible el soporte directo.

La resolución de un incidente típico comienza con que un SCS cree una nueva entrada en el gestor de tareas/tickets/incidencias. Esto garantiza que exista trazabilidad del incidente.

A continuación, el SCS diagnosticará el problema. Si éste requiere una corrección por parte de Lokad, el SCS movilizará de inmediato los recursos necesarios para resolverlo, normalmente él mismo.

Finalmente, una vez solucionado el problema, el SCS evaluará la verdadera causa raíz del incidente reportado, incluso si el informe finalmente fue diagnosticado como una no incidencia. Generalmente, existe un problema subyacente en algún lugar que debe ser abordado. Al tratar la causa raíz más profunda, Lokad elimina proactivamente problemas similares en el futuro.

9.5 Si se reporta un defect fuera de la herramienta de Gestión de Incidentes – a través de otro canal, como email – ¿lo registrará en la herramienta tan pronto como se presente para garantizar un seguimiento y cumplimiento adecuados?

Sí. Es una 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 tareas/tickets/incidencias. Esta práctica facilita un seguimiento y cumplimiento exhaustivos.