Ya hemos comentado en más de una ocasión múltiples razones por las que el arranque ERP se demora. En esta ocasión hablaremos sobre un escaso y lento poblamiento, alimentación e introducción de los datos en el nuevo sistema.
Lo primero que habría que analizar es cual es el motivo por el que el registro de datos es lento:
- ¿Es un usuario concreto?
- ¿Es un departamento el que no está procesando datos?
- ¿Son muchos usuarios?
- ¿Están «enfrascados» en otras tareas no relevantes al ERP?
- ¿Carecen de la formación necesaria para el uso de la herramienta?
- ¿Disponen de la información o han de capturarla previamente?
- …
Es importante plantearse éstas y otras preguntas con la finalidad de canalizar los esfuerzos correctivos en los puntos débiles.
La mayoría de arranques siempre tienen un carácter presencial durante varias semanas mínimo (en alguna ocasión hasta meses o incluso años), por lo que te vas fijando en los distintos usuarios y vas captando la sensibilidad de cada uno de ellos hacia el nuevo sistema. Algunos, simplemente van lentos (su formación ha sido insuficiente), otros se quedan hipnotizados por las nuevas pantallas sin saber qué hacer con el ratón (su formación no es que sea deficiente, es que o no la han tenido o no les interesaba mucho), otros ya operan casi como en el sistema viejo (están interesados en el nuevo sistema), otros los oyes quejarse y llamar la atención constantemente de los formadores o del jefe del proyecto con comentarios inoportunos (resistentes al cambio), etc. (En alguna ocasión, a estos últimos, he tenido que recomendar a algún usuario de forma poco sutil que focalice su esfuerzo en sumar en vez de restar).
Conociendo los motivos por los que las transacciones no van a buen ritmo, entonces podremos reclamar al jefe interno del proyecto para analizar las causas y ver si hay dedicar esfuerzos extra de formación a algunos usuarios, realizar una nueva campaña de comunicación e información sobre la conveniencia del nuevo sistema a otros, «recriminar» la inacción de otros, etc. En cualquier caso, se buscarán las opciones necesarias para tratar de alinear a los usuarios con el sistema en aras de lograr el éxito del proyecto, si bien, se debe ser contundente también con la dejación de funciones, la inacción y la pasividad.
Si finalmente el jefe del proyecto interno es quien está paralizando el arranque, debemos sentarnos y tratar de conocer los verdaderos detalles de primera mano (funcionalidad no suficientemente probada, detección de errores, desconfianza hacia el sistema, …).
Una vez destapado el origen de los problemas que están causando el retraso del arranque debemos tratar de matizar sus apreciaciones si son en parte infundadas o reconocerlos y comprometernos a darle soluciones, tratando de priorizar aquellas más críticas. No vendría mal recordar, de forma muy sutil, que existen unos documentos firmados validando las fases previas del arranque, por lo que si hay problemas es porque no se ha realizado la verificación de forma adecuada, si bien, por parte del implantador se le debe brindar toda la ayuda para el éxito del proyecto. Recordemos que es preferible reducir el margen en un proyecto que fracasar en la implantación.
|
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
Un comentario
Pingback: "Inactividad e inacción" en el...