“Nightmare in Procurement Street” 6ª y última parte – Pruebas y entrenamiento + Quick wins vs. Prueba piloto

public procurement

Hace un par de semanas Spend Matters y GEP dimos un seminario web en donde platicamos algunos puntos a considerar durante la implementación de un proyecto de Compras a Pago (Procure-to-pay) para evitar convertirlo en una pesadilla. Esta es la sexta y última parte de esta serie de artículos relacionados con este seminario, en la primera parte comentamos sobre un par de premisas iniciales para los proyectos de “Procure-to-pay” y algunos puntos a considerar previo al arranque del proyecto – “Nightmare in Procurement Street – 1ª PARTE",, en la segunda parte nos enfocamos en algunas consideraciones a realizar durante la etapa de diseño “Nightmare in Procurement Street – 2ª PARTE”, la tercera estuvo relacionada con la integración de sistemas como punto clave para que la implementación de una solución de P2P tenga un éxito real de transformación en el área de compras “Nightmare in Procurement Street – 3ª PARTE”, en la cuarta parte platicamos sobre la responsabilidad de compras en la administración del proyecto –NO Sistemas “Nightmare in Procurement Street – 4ª PARTE”., en la quinta parte y casi última reforzamos la idea de no olvidar la “P” de Pago en las soluciones de “Compras a Pago”, así como la importancia de los proveedores “Nightmare in Procurement Street – 5ª PARTE”.

Las pruebas y el entrenamiento de usuarios

La realización de pruebas es una etapa obligatoria en proyectos de implementación de soluciones tecnológicas; y aunque el área de sistemas tiene un rol crítico para probar temas tales como la integración de sistemas, cargas de trabajo, infraestructura, seguridad, comunicaciones, etc., las áreas de negocio —Compras, Finanzas, RH, Operaciones, etc.— requieren probar el flujo de sus procesos y los escenarios.

La realización de scripts técnicos y funcionales son indispensables para realizar las pruebas, documentarlas correctamente y evitar la pesadilla de los típicos bomberazos durante la operación. El entrenamiento, al igual que con los proveedores, requiere de opciones para tomarlo —videos bajo demanda, seminarios web, manuales interactivos, train de trainers, mesas de ayuda, etc.—, evitando al máximo obstruir el trabajo del día a día. No olvidemos que una de las pesadillas más temidas en cualquier proyecto que involucre nuevas tecnologías de información, es la falta de adopción de las mismas; por lo que una buena estrategia de entrenamiento, una buena campaña de comunicación, y la certeza de que el nuevo sistema simplificará el trabajo de los usuarios involucrados, son factores de éxito.

Quick Wins vs. Prueba Piloto

Durante el seminario hubo la opinión por parte de GEP que las empresas en muchas ocasiones buscan obtener ganancias rápidas o ‘quick wins’ durante la fase de prueba piloto, y que normalmente estas ganancias rápidas no permiten probar de manera certera la complejidad real del sistema lo que se convertirá en una “pesadilla” posterior a la prueba piloto, ya que en muchas ocasiones el «equipo A» de la implementación abandona el proyecto una vez terminada la prueba. Es claro que la experiencia de GEP es amplia implantando soluciones de compras —por lo que el recalcar el hecho no es menor cosa—.

Las ganancias rápidas en los proyectos sobre todo en los relacionados con el gasto, son importantes y en muchos casos necesarios para financiar el mismo proyecto; sin embargo, la prueba piloto está más enfocada en probar la funcionalidad. Hay que procurar probar los escenarios críticos e importantes para el negocio, con retos claves y pruebas de estrés, que nos asegure un despliegue (roll-out) exitoso.

Bajo el escenario que nos comentó GEP, es importante transmitir desde el inicio a todas las áreas involucradas —socios internos— que esto no es un proyecto con principio y fin, sino un viaje que tendrá retos, mejoras y beneficios en el camino, pero como dice el dicho “Es un viaje —cuento— de nunca acabar”.

Esperamos esta serie de artículos relacionados con «Cómo evitar hacer de una implementación de un proyecto de Procure-to-pay una pesadilla», hayan sido de tu interés, no dejes de retroalimentarnos mucho lo agradeceremos.

Discuss this:

Your email address will not be published. Required fields are marked *