En la mayoría de proyectos en Supply Chain y Logística hay demasiado en juego. Sin importar si se trata de proyectos de mejoramiento productivo, investigación y desarrollo, implementación tecnológica, o de cualquier otra índole, las magnitudes de los efectos de estos proyectos y todo lo que depende de ellos es enorme. Aún así, existen casos muy frecuentes en los que los proyectos en logística y cadena de abastecimiento fallan de manera estrepitosa a pesar de enormes cantidades de esfuerzo y dinero invertidos en lograr su éxito. ¿Por qué?

El número de factores involucrados en un proyecto es gigante, y las posibles causas del fracaso de un proyecto tienen hacia lo inconmensurable. Sin embargo, existe un patrón claramente identificable que hace que muchos proyectos fallen de manera casi homóloga, y que sin importar el tipo de proyecto, llevan a la ruina todo el esfuerzo realizado. Este común denominador entre muchos proyectos fallidos sobresale por encima de cualquier otra causa probable, y delinea claramente una senda que, si usted como profesional en Supply Chain y sus proyecto no desean seguir, es mejor observarla y evadirla con mucho cuidado y determinación.

 

El Alcance del Proyecto (o Scope Statement).

Tal como lo despliegan en su mayor expresión los diferentes compendios de buenas prácticas en la Gestión de Proyectos (dentro de los que se destaca PMI, entre otros), el Alcance del Proyecto, o Scope Statement en Inglés, es una parte fundamental del direccionamiento y la alineación que determinan el grado de éxito de un proyecto desde sus inicios. El Alcance del Proyecto puede ser el héroe de la historia, si está bien definido, o por el contrario convertirse en el antagonista más aguerrido si desde el principio del proyecto está fuera de proporciones.

en Logística.la hemos sido testigos e incluso partícipes de diversos proyectos en Supply Chain y Logística, que han abarcado temas de implementación de tecnología, modificación de procesos productivos, gestión de demanda, entre otros. Estos proyectos que pudimos presenciar, a pesar de contar con equipos multidisciplinarios de personas capacitadas para llevarlos al éxito, a pesar de contar con  recursos económicos, tecnológicos y técnicos para lograr su cometido, incluso a pesar de contar con el apoyo constante de consultores externos, fallaron en sus objetivos y necesitaron más tiempo, dinero y recursos de otros tipos para llevarlos a feliz término. En cada uno de ellos el problema fue, desde un comienzo, un alcance del proyecto mal planteado. Esto sucede muy a menudo, distorsionando la objetividad y pertinencia del alcance y enfoque de un proyecto a causa de intereses particulares, internos o externos, de una parte de la organización, la disponibilidad de recursos, la estrategia corporativa, etc.

Este artículo no pretende suplir el conocimiento acerca de las mejores prácticas en gestión de proyectos. Para esos fines, invitamos al lector a aproximarse a los diferentes compendios de buenas prácticas en Gestión de Proyectos.

Un ejemplo «sencillo»:

Este ejemplo hipotético está diseñado para evidenciar la importancia de la definición correcta del alcance y enfoque de un proyecto en Supply Chain.

Un proyecto de implementación de software ERP en una planta de producción de una empresa manufacturera es requerido por la casa matriz. La alta dirección define, a manera de meta principal del proyecto, una fecha específica en la que el nuevo sistema debe estar operando y la manufactura debe monitorearse y controlarse a partir del mismo. Lo que busca la compañía es:

• facilitar las operaciones de manufactura (ya que para eso está construido el software)
• darle visibilidad a la organización sobre el proceso productivo y su supply chain.
• alinear los procesos contables en los que se soportan las operaciones.

El proyecto inicia, y tiene varios retrasos ya que el departamento de tecnología no se comunica suficientemente con la dirección de manufactura para implementar el software de manera correcta. Al momento de las primeras pruebas, el software no describe la realidad del proceso productivo. Este problema es superado al reordenar la lógica del sistema, pero una vez más se presentan problemas al dejar de lado la dimensión contable del proceso productivo, donde no se han integrado las variables del valor agregado a los productos y el sistema refleja los productos en proceso sin ningún valor agregado (contablemente).

La fecha de culminación y lanzamiento del sistema en vivo se acerca, pero aún hay muchos inconvenientes. El departamento de tecnología logra poner en sintonía las dimensiones contables del sistema, y logra que el sistema le permita a Manufactura controlar el proceso desde desde él, aunque con algunas interacciones siendo aún manuales. La fecha límite requerida por la casa matriz llega y el sistema comienza funcionar en vivo ese mismo día comenzando con el turno de producción de las 6 AM. El sistema completo colapsa pues alrededor de las 10:45 AM pues está lanzando órdenes de producción que parecen ilógicas. Al revisar el problema encuentran que hubo un cambio reciente en la configuración de la planta, pero que no fue comunicado por parte del departamento de manufactura para su actualización en el sistema. Esto también provoca que el módulo MRP del software lance órdenes erradas de pedido de materias primas a los proveedores, que están comunicándose unos minutos más tarde con la compañía para verificar si esas cantidades exorbitantes de las órdenes son correctas.

Al mismo tiempo, las cantidades de las órdenes de producción no coinciden con las cantidades finales de productos. El sistema bloquea dichas órdenes, y no permite finalizarlas adecuadamente para despachar la mercancía con su etiqueta y código de trazabilidad. Los despachos previstos para el día se retrasan y hacia media tarde, hay una enorme fila de camiones esperando para poder cargar los pedidos de los clientes, que aún no pueden ser empacados ni despachados a falta de las etiquetas y las órdenes cerradas y verificadas de cada pedido… Es el día más caótico en la historia de la empresa desde hace mucho tiempo.

El proyecto se declara fallido. En la reunión de emergencia del día siguiente, hay una acalorada discusión en donde todos se inculpan mutuamente sin entender cómo todo pudo salir tan mal. Claramente el error fue humano, el sistema ERP sólo hizo lo que fue programado y configurado para hacer.

¿Cuál fue el problema?

Muchas cosas estuvieron mal, pero lo concerniente al enfoque del proyecto es que, en primer lugar, un proyecto del que dependen las operaciones completas de la empresa no debe estar sujeto únicamente a la fecha de puesta en marcha del sistema. Este alcance del proyecto debió incluir muchos más aspectos, incluyendo detalles muy precisos sobre la fiabilidad con la que la manufactura puede controlarse, la exactitud del comportamiento contable del sistema, y la garantía de que la organización está preparada para trabajar con el nuevo sistema incluyendo los cambios operacionales y administrativos que se van presentando con el tiempo. Desafortunadamente, a causa de la presión de la alta dirección por lanzar el sistema en vivo en la fecha seleccionada, se pusieron en peligro muchas de las órdenes de pedido de los clientes, la capacidad operacional de la compañía, sus finanzas y su reputación en el mercado.

Retomando, lo que realmente deseaba la compañía con este proyecto era:

• facilitar las operaciones de manufactura (ya que para eso está construido el software)

• darle visibilidad a la organización sobre el proceso productivo

• alinear los procesos contables en los que se soportan las operaciones.

En su lugar, desafortunadamente, enfocó el proyecto y su puesta en marcha en una fecha de lanzamiento.

—

Pregúntese a usted mismo y a su equipo ¿El alcance de nuestro proyecto es exactamente el más apropiado?

Como hemos mencionado anteriormente, el alcance de este artículo no incluye detalles acerca de las mejores prácticas en Gestión de Proyectos. Sugerimos aproximarse al Project Management Institute, así como familiarizarse con otras mejores prácticas y metodologías existentes.

Project Management Institute: http://www.pmi.org/

La siguiente infografía fue publicada originalmente en: https://www.wrike.com/blog/a-crash-course-in-project-management-methodologies-infographic/