Top
TAKTICTAKTIC Errores al finalizar un proyecto ERP
errores al finalizar un proyecto ERP

Errores al finalizar un proyecto ERP

Si a estas alturas, no hemos caído en ninguno de los errores que tratamos en anteriores entradas del blog, ¡enhorabuena!, ya solo queda afrontar el cierre de proyecto y evitar los errores al finalizar un proyecto ERP.

En este punto nos encontramos en una situación crítica puesto que posiblemente el calendario esté más que ajustado, los costes previstos y reales sean ya muy parecidos (con suerte) y a los recursos humanos involucrados en el proyecto esté bastante “tenso”.

Depende de cómo se haya desarrollado el proyecto y de la metodología usada, pero lo más común es que todavía tengamos que cerrar una serie de tareas de vital importancia.

 

La validación del producto

En esta fase final, tenemos que certificar, que el producto entregado por el proveedor cubre las necesidades detalladas en el alcance y por lo tanto los objetivos planteados para el proyecto.

Si los requerimientos no estaban claros, bien definidos y bien trazados, esta tarea se hace prácticamente imposible.

La validación implica un conocimiento exhaustivo de los procesos de negocio y de la funcionalidad del software de gestión. Asimismo, el responsable de la aceptación debe haber participado en el proyecto para, explicar las necesidades, entender la aplicación y probar a detalle las funcionalidades implementadas.

Pero esta validación no significa que el proyecto haya acabado, todavía quedan un par de obstáculos que salvar.

 

La formación a usuarios finales

El conocimiento por parte de los usuarios finales del manejo del sistema erp, es una de las claves del éxito o fracaso del proyecto.

Por muy bien que se haya definido los requisitos, por muy bien que estén implementados y por mucho que la solución cubra los objetivos inicialmente planteados, si los pilotos no saben conducir la nave no hacemos nada.

Un conocimiento detallado del erp, para que los usuarios sepan plasmar todos los procesos de trabajo, no solo aporta un manejo fluido del sistema, en el día a día, sino que es una fuente de información para la futura mejora continua de la solución.

En este punto podría darse el caso, que afloren errores pasados, tales como la mala gestión de expectativas o la incorrecta identificación de usuarios clave. ¿Cuántas veces te encuentras en esta fase con usuarios que conocen información crítica de negocio que no han salido a colación antes?.

 

La migración de datos

La base de datos debe contener la información precisa en el momento de que pasemos de un proyecto en curso a un proyecto productivo.

Para ello debemos disponer de la información completamente actualizada, como mínimo, de: datos maestros, saldos contables, cartera viva de clientes y proveedores y stocks.

El modo en el que planifiquemos tanto la extracción, como la depuración, y la  carga de esta información es crítico de cara a hacer una carga de datos lo más rápida y limpia posible. Todo esto sujeto a las ya conocidas políticas de privacidad de la información, que no hacen más que hacernos nuestro día a día más fácil.

 

La validación del Proyecto

Antes hemos validado el producto, ahora deberíamos validar el proyecto. Tenemos que certificar, no sólo que lo que me han entregado es lo que yo he pedido, sino que además las personas que lo vamos a usar sabemos cómo hacerlo y estamos dispuestos y preparados para empezar a hacerlo en la fecha que se determine.

 

La puesta en Producción

En TAKTIC pensamos que uno de los mayores errores que podemos cometer en este tipo de proyectos, es incluir la puesta en producción, como una fase del proyecto de implantación de una solución erp.

Una buena gestión del proyecto debería contemplar una finalización del mismo en el momento en el que se valide la puesta en producción.

Si la puesta en marcha se considera como parte del proyecto, se corre el riesgo de no cerrar nunca, las incidencias derivadas de la puesta en producción, el mal uso de la aplicación por parte de los usuarios, la necesidad del cliente de incluir nuevas funcionalidades “al mismo precio” o del proveedor de cerrar el proyecto, producen fricciones que no ayudan en absoluto a la consecución de los objetivos.

Una recomendación sería cerrar el proyecto en el momento de la validación final, si el producto ha sido aceptado por el cliente, los usuarios están formados, y los datos cargados son los correctos, ¿porque no hacerlo?

 

Carlos Fiol Ayala
Carlos Fiol Ayala

Si continuas utilizando este sitio, aceptas el uso de las cookies. Más información

Las opciones de cookie en este sitio web están configuradas para "permitir cookies" para ofrecerte una mejor experiéncia de navegación. Si sigues utilizando este sitio web sin cambiar tus opciones o haces clic en "Aceptar" estarás consintiendo las cookies de este sitio.

Cerrar