QUICKSTART DEL GRP
SpoC - Consultor

Principales roles para la Implementación del GRP (Government Resource Planning)

A continuación se describen los principales roles de trabajo durante la implementación del sistema:

1) Punto Único de Contacto (SPoC) Single Point of Contact 

• Es el responsable de la transmisión de conocimientos de su negocio y hasta coordina la intervención de los usuarios claves de ser necesario.

• Este responsable tiene que tener la autoridad de toma de decisiones, coordinar con usuarios claves, y gestionar el cambio.

• Es necesario que el SPoC también participe en su propio aumento de habilidades a través del autoaprendizaje a través de la documentación del GRP y la prueba de funcionalidades.

   El Consultor GRP

• Como proveedor del sistema, asegura la consistencia general de la implementación en el GRP y comparte su experiencia en términos de buenas prácticas.

• No está involucrado en el proceso de toma de decisiones desde el punto de vista comercial ni en procesos precisos y procedimientos internos de la empresa (a menos que sea una solicitud específica o una excepción).

•  brinda capacitación funcional al SPoC para que pueda transmitir este conocimiento a sus colaboradores.

2) Alcance del Proyecto. 

Para asegurarse de que todas las partes estén siempre alineadas, es necesario definir y hacer que el alcance del proyecto evolucione mientras se persiga la implementación del proyecto.

Puntos claves:

1. Una definición clara de las necesidades iniciales.

2. Favorecer una implementación en varias fases para lograr un producto mínimo viable.  

3. Favorecer un enfoque que ayude a identificar brechas y aplicar acciones correctivas al principio de la implementación.

4. Adoptar características estándar como una prioridad, el GRP ofrece un gran entorno para implementar pequeñas mejoras (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 fluida de su nueva herramienta.

3) Manejo de las 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 inicio del proyecto:

• Alinear con el enfoque del proyecto: tanto una división de roles y responsabilidades como una descripción clara de los modos operativos (validación, resolución de problemas, etc.) son cruciales para el éxito de una implementación del ERP. Por lo tanto, se recomienda encarecidamente que se tome el tiempo necesario al comienzo del proyecto para alinearse con estos temas y verificar periódicamente que este sigue siendo el caso.

• Centrarse en el éxito del proyecto, no en la solución ideal: El objetivo principal del SPoC y del Consultor es llevar a cabo el proyecto que se les encomienda con el fin de brindar 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 80-20: centrarse en el 80% de las necesidades expresadas y eliminar el 20% restante de los objetivos más desfavorables en términos de relación costo / 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 son siempre EXPLÍCITAS : las brechas entre lo que se espera y lo que se entrega son a menudo 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 el proveedor del ERP permitirá identificar el vacío a 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 el QUIÉN, y el Consultor que dará una respuesta al CÓMO.

• La Prueba de Concepto: Una versión simplificada, un prototipo de lo que se espera que coincida en las principales líneas de 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 sumará una transparencia total 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 tanto, evitaremos basar nuestro trabajo en hipótesis sin comprobar previamente su veracidad.

Por supuesto, esta lista puede completarse con otras herramientas que se ajusten más adecuadamente a las realidades y necesidades de su proyecto.

4) Estrategia de Comunicación.

El propósito de la metodología es asegurar que los usuarios finales se apropien rápidamente de la herramienta. Por tanto, la comunicación eficaz es fundamental para el éxito de este enfoque.

Su optimización, por tanto, nos llevará a seguir esos principios:

• Compartir la documentación de gestión del proyecto : la mejor manera de garantizar que todas las partes interesadas 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 las cuales el nivel de prioridad y el administrador están claramente definidos.

• Informar 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 formación sobre la solución estándar o personalizada.

5) Personalizaciones y Desarrollos

El GRP 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.  

Ésta es la razón por la que se recomienda:

• Desarrollar solo por una buena razón: La decisión de desarrollar siempre debe tomarse cuando la relación costo-beneficio sea positiva (ahorro de tiempo en el día a día, 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 cercana sea la solución al estándar, más ligero y fluido será el proceso de migración y menores serán los costes de mantenimiento para ambas partes. 

Reemplazar, sin replicar: Hay una buena razón para que se haya tomado 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 de cambios tanto en términos de cómo se utilizará el software como a nivel de los procesos de negocio de la empresa.

6) Principios de Prueba y Validación.

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

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

• Gestión de cambios : cuando es necesario realizar un cambio en la solución, la brecha indicada se debe a:

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

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

7) 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 el lanzamiento a producción se produzca a tiempo. 

Para hacer esto lo antes posible, se decidirá:

• No importar nada : A menudo sucede que después de la reflexión, la importación del historial de datos no se considera necesaria, siendo estos datos, además, guardados fuera del GRP y consolidados para informes posteriores.

• Para 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, remitos, recibos), 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.

Para importar después del lanzamiento de la producción: cuando el historial de datos debe integrarse con el GRP principalmente para fines de generación de informes, está claro que estos 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.