Si bien no siempre ha sido fácil gestionar la última fase de un proyecto de implantación ERP, últimamente asistimos a casos de un desconocimiento profundo acerca de las «reglas» que rigen la transición entre el arranque del proyecto y la entrada en mantenimiento. A este hecho además, hay que sumarle el condicionado por la situación económica actual, donde la financiación por parte de las entidades bancarias es inexistente y donde el proveedor del servicio es el que realiza esa función, prolongando el pago de proyectos a muchos meses después de haberse concluido. El servicio proporcionado por el proveedor frente a los pagos realizados por el cliente está provocando, un desequilibrio en las relaciones de poder, donde se llega a situaciones de secuestro del pago si no se accede a múltiples exigencias, algunas de las cuales tienen más de arrogancia que de necesidad real.
Hay clientes, como también hay proveedores, que no han terminado de entender que esta relación, haciendo una analogía con organismos biológicos, debe tener más de simbiosis que de parasitismo. Sobre todo porque las primeras tienden a perdurar en el tiempo, mientras que las segundas tienden a liquidarse cuanto antes, lo que puede percibirse a corto plazo como un éxito, sin duda, redundará en un grave fracaso.
Para que el cierre de un proyecto ERP no se haga en falso y permita una entrada ordenada en fase de mantenimiento, deberíamos realizar antes las siguientes acciones:
- Formación a los usuarios finales, ya sea a todos ellos o formando a formadores, según convenga.
- Entrega de documentación detallada de ciertos procesos claves y diferenciales. No de todos los procesos de la organización, pero sí al menos de aquellos que han requerido un diseño funcional específico para ella, y que ha conllevado un desarrollo. A ser posible, con screenshots, diagramas de flujo, explicación clara de los procesos y campos, etc.
- Instalación del entorno de pruebas donde se realizará la formación, permitiendo a los usuarios realizar las actividades propias de la formación. A ser posible, poblado de datos de la propia organización.
- Migración definitiva de los datos en el entorno de producción. Por supuesto la migración ha sido validada en fases anteriores, por lo que ésta no puede dar lugar a errores en este momento. Puede que haya otros datos que hayan sido migrado anteriormente, pero siempre habrá algunos que tendrán que ser retrasados hasta este punto.
- Configuración de las últimas funcionalidades por parte de los usuarios. Reglas, políticas, valores por defecto, valores obligatorios, …
- Preparación y adecuación del entorno productivo. Últimos ajustes de los recursos dedicados al entorno de producción (resizing si fuera necesario, sobre todo en entornos virtualizados).
- Configuración de menús, roles y permisos de usuarios. Determinación de menús, roles y permisos y asignación a cada uno de los usuarios en función de los distintos perfiles.
- Comunicación con los users keys e incluso los usuarios. Mitigar la resistencia al cambio es clave para lograr el éxito del proyecto.
- Sistema de issue tracking a disposición de los usuarios. Podrán reportar las distintas incidencias y comprobar el estado o evolución de éstas (debidamente clasificadas por criticidad, tipo de incidencia, fecha, usuario que la reporta, …). Ello también permite dar visibilidad de las distintas soluciones aportadas al proyecto. La tipología de incidencias también nos aportará una visión sobre si existe una carencia de formación a los usuarios, a errores de éstos, a errores de la aplicación que no han sido correctamente testados, si son nuevas funcionalidades, …
- Preparar el plan de transición. En base a las incidencias reportadas pendientes, definir y negociar con el cliente cuales van a ser resueltas antes de la entrada en soporte.
- Firma validación proyecto. La firma conlleva la aceptación formal del proyecto, y la facturación del resto pendiente del proyecto, así como el plan de pagos.
- Definir el plan de soporte. Ya sea a través de una bolsa de horas (consumo de horas de la bolsa), una facturación periódica (facturación por consumo de horas y/o materiales) o por facturación evolutiva (facturación con cada nuevo proyecto), es necesario concretar la modalidad con el cliente.
Considerando estas pautas básicas, el cierre de un proyecto ERP y su entrada en fase de mantenimiento debería ser algo natural y sin sorpresas para ninguna de las partes.
(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).
Autor: Sergio Martínez|
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
Saludos !!
Llevo varios años trabajando en Implantación de software para diferentes sectores comerciales , me identifico mucho con tus comentarios respecto a como el cliente valora un software solo por la parte económica( aunque este no dejara de ser factor por la parte costo beneficio) no por lo que le puede aportar en la empresa en términos de productividad de su personal ahorrando la duplicidad de esfuerzos entre un departamento y otro , y mucha veces tienen la idea de que si el software no lo hizo un gringo no es bueno, despreciando la mano de obra local .
Hola Jorge.
En más de una ocasión, aun a costa de perder la venta, trato de aconsejar al futuro cliente sobre la conveniencia del software que más se le adecúe a sus necesidades, independiente de la notoriedad del fabricante. Es un grave error pensar que el mejor software es aquél que más clientes tiene, o aquél cuyo coste económico es mayor, o aquél que tiene miles de prestaciones que seguramente jamás usaré.
Muchas gracias por tu comentario. Un saludo.