Alcance del proyecto

Para asegurarse de que todos los interesados ​​ involucrados estén siempre alineados, es necesario definir y hacer que el alcance del proyecto evolucione mientras se lleve a cabo la implementación del proyecto.

Una definición clara del alcance inicial del proyecto

una definición clara de las necesidades iniciales es crucial para garantizar que el proyecto funcione sin problemas. De hecho, cuando todos los interesados ​​comparten la misma visión, la evolución de las necesidades y el proceso de toma de decisiones resultante son más simples y más claros.

Fases del proyecto

favorecer una implementación en varias fases coherentes que permita lanzamientos de producción regulares y una adquisición en constante evolución de Odoo por parte de los usuarios finales ha demostrado su eficacia con el tiempo. 

Este enfoque también ayuda a identificar brechas y aplicar acciones correctivas al inicio de la implementación.

Desarrollos específicos en el proyecto

Odoo ofrece un excelente entorno para implementar mejoras leves (personalizaciones) o más importantes (desarrollos). Sin embargo, se preferirá la adopción de la solución estándar con la mayor frecuencia posible para optimizar los tiempos de entrega del proyecto y proporcionar al usuario una estabilidad a largo plazo y una escalabilidad de fluidos de su nueva herramienta. Idealmente, si aún se lograra una mejora del software, su implementación se llevará a cabo después de un experimento del estándar en producción.

Estrategia de comunicación

El propósito de la metodología QuickStart es garantizar la propiedad rápida de la herramienta para los usuarios finales. 

La comunicación efectiva es, por lo tanto, crucial para el éxito de este enfoque. Su optimización, por lo tanto, nos llevará a seguir esos principios

• Compartir la documentación de gestión del proyecto: la mejor manera de garantizar que todos los interesados ​​en un proyecto tengan el mismo nivel de conocimiento es proporcionar acceso directo al documento de seguimiento del proyecto (Organizador del proyecto). 

• Este documento contendrá al menos una lista de tareas a realizar como parte de la implementación para la cual el nivel de prioridad y el gerente están claramente definidos.

• Informe información esencial : para minimizar el tiempo de documentación a lo esencial, seguiremos las siguientes buenas prácticas:

• Las actas de las reuniones se limitarán a decisiones y validaciones;

• Los estados del proyecto solo se establecerán cuando se alcance un hito importante;

• Se organizarán sesiones de capacitación sobre la solución estándar o personalizada.

Personalizaciones y desarrollo

Odoo es un software conocido por su flexibilidad y su importante capacidad de evolución. Sin embargo, una cantidad significativa de desarrollo contradice una implementación rápida y sostenible. Esta es la razón por la cual se recomienda

Desarrolle sólo por una buena razón

la decisión de desarrollar siempre debe tomarse cuando la relación coste-beneficio es positiva (ahorrando tiempo a diario, etc.). 

Por ejemplo, será preferible realizar un desarrollo significativo para reducir el tiempo de una operación diaria, en lugar de una operación que se realice solo una vez por trimestre. En general, se acepta que cuanto más se acerca la solución al estándar, más liviano y fluido es el proceso de migración, y menores los costes de mantenimiento para ambas partes. Además, la experiencia nos ha demostrado que el 0% de las solicitudes de desarrollo iniciales se eliminan después de algunas semanas de usar el estándar Odoo.

Reemplazar sin replicar

hay una buena razón para tomar la decisión de cambiar el software de administración. En este contexto, el momento de la implementación es EL momento adecuado para aceptar e incluso ser un iniciador del cambio, tanto en términos de cómo se utilizará el software como a nivel de los procesos comerciales de la empresa.

Importaciones de datos

Importar el historial de datos transaccionales es un tema importante y debe responderse adecuadamente para permitir que el proyecto funcione sin problemas. De hecho, esta tarea puede llevar mucho tiempo y, si su prioridad no está bien definida, evitar que la producción suceda a tiempo. Para hacer esto lo antes posible, se decidirá:

No importar nada

Cuente cuál es el valor para el
cliente de esta característica.

Importar una cantidad limitada de datos

Antes de entrar en producción cuando el historial de datos se relaciona con la información que se está procesando (órdenes de compra, facturas, proyectos abiertos, por ejemplo), la necesidad de tener esta información disponible desde el primer día de uso en producción es real. En este caso, la importación se realizará antes del lanzamiento de la producción.

Importar después del lanzamiento de producción

Cuando el historial de datos debe integrarse con Odoo principalmente con fines informativos, está claro que pueden integrarse en el software de forma retrospectiva. En este caso, el lanzamiento de producción de la solución precederá a las importaciones requeridas.

Principios de prueba y validación

Ya sea que se realicen o no desarrollos en la implementación, es crucial probar y validar la correspondencia de la solución con las necesidades operativas de la empresa.

 

Comience con el cliente - descubra lo que quiere y déselo.

Distribución de roles: en este contexto, el Consultor será responsable de entregar una solución correspondiente a las especificaciones definidas; SPoC deberá probar y validar que la solución entregada cumple con los requisitos de la realidad operativa.

Gestión del cambio

Cuando es necesario realizar un cambio en la solución, la brecha notoria es causada por:

·         Una diferencia entre la especificación y la solución entregada: esta es una corrección de la cual el Consultor es responsable.

·         Una diferencia entre la especificación y los imperativos de la realidad operativa: este es un cambio que es responsabilidad de SPoC.

 

La gestión de expectativas

La brecha entre la realidad de una implementación y las expectativas de los futuros usuarios es un factor crucial. Se deben tener en cuenta tres aspectos importantes desde el comienzo del proyecto:

Alinee con el enfoque del proyecto

Una división clara de roles y responsabilidades y una descripción clara de los modos operativos (validación, resolución de problemas, etc.son cruciales para el éxito de una implementación de Odoo. 

Por lo tanto, se recomienda encarecidamente tomar el tiempo necesario al comienzo del proyecto para alinearse con estos temas y verificar regularmente que este sea el caso.

Concéntrese en el éxito del proyecto

No en la solución ideal: el objetivo principal de la SPoC y el Consultor es llevar a cabo el proyecto que se les ha encomendado para proporcionar la solución más eficaz para satisfacer las necesidades expresadas. 

Este objetivo a veces puede entrar en conflicto con la visión del usuario final de una solución ideal. En ese caso, el SPoC y el consultor aplicarán la regla 0-20: enfóquese en el 0% de las necesidades expresadas y elimine el 20% restante de los objetivos más desventajosos en términos de relación coste / beneficio (esas proporciones pueden, por supuesto, cambian con el tiempo). 

Por lo tanto, se considerará aceptable integrar una manipulación que requiera más tiempo si se observa un alivio global. También se pueden proponer cambios en los procesos comerciales para perseguir este mismo objetivo.

Las especificaciones siempre son EXPLICITAS

Las brechas entre lo que se espera y lo que se entrega a menudo son una fuente de conflicto en un proyecto. Para evitar estar en esta delicada situación, recomendamos utilizar varios tipos de herramientas *:

El análisis GAP

La comparación de la solicitud con las características estándar propuestas por Odoo permitirá identificar la brecha que se debe llenar con desarrollos / personalizaciones o cambios en los procesos comerciales.

La historia del usuario

Esta técnica separa claramente las responsabilidades entre el SPoC, responsable de explicar el QUÉ, el POR QUÉ y la OMS, y el Consultor que proporcionará una respuesta al CÓMO.

La prueba de concepto 

Es una versión simplificada, un prototipo de lo que se espera que coincida en las líneas principales de los cambios esperados.

La maqueta

En la misma idea que la Prueba de concepto, se alineará con los cambios relacionados con la interfaz.

 

A estas herramientas se agregará una transparencia completa sobre las posibilidades y limitaciones del software y / o su entorno para que todos los interesados  ​​   en el proyecto tengan una idea clara de lo que se puede esperar / lograr en el proyecto.       Por lo tanto, evitaremos basar nuestro trabajo en hip   ó   tesis sin verificar su veracidad de antemano.

Por supuesto, esta lista puede completarse con otras herramientas que satisfagan mejor las realidades y necesidades de su proyecto.