“El proveedor dijo que serían 4 meses, ya llevamos un año, y todavía no acabamos.”
“En algunos casos tengo más licencias de las que no necesito, mientras que de las que sí necesito, compré muy pocas”
“No se supone que los consultores hacían todo el trabajo, por qué me están pidiendo personal?”
Ha escuchado alguna de estas quejas antes?
Los proveedores de sistemas tipo ERP, generalmente presentan en sus propuestas una versión editada de lo que conlleva el proceso de implantación del mismo. Decimos editada porque especifican claramente cuáles serían sus tareas y responsabilidades, así como las exenciones de responsabilidad, pero no indican, con el mismo nivel de detalle, cuáles serían las del contratante.
Son estas omisiones las que después generan malos entendidos y sinsabores en la ejecución del proyecto y el origen de las expectativas no cumplidas.
A continuación, presentamos diez errores muy comunes que cometen las empresas al ejecutar un proyecto de implementación de sistemas.
- No ejecutar el levantamiento de necesidades y de los procesos críticos del negocio
Difícilmente encontraremos un ERP que se ajuste 100% a las necesidades de los procesos y operaciones de nuestra empresa, es por ello que correspondería llevar a cabo, como tarea previa a la adquisición, un análisis y levantamiento de requerimientos y procesos críticos del negocio. Es decir, aquéllos que necesitamos se cumplan porque de lo contrario ponemos en riesgo la operación de la empresa.
Lo que ocurre con frecuencia es que las empresas inician el proceso de adquisición con los oferentes sin contar con esta información. Como es de esperar, el oferente, a su propio costo, solamente puede hacer un estudio somero; lo básico para confirmar si el sistema se ajusta lo suficiente al negocio. Las adecuaciones que haya que hacer se identificarán después, durante la ejecución del proyecto.
Tenga presente que es el Contratante, o sea su empresa, quien deberá costear estas adecuaciones, y que, por supuesto, el plan de proyecto que le hayan presentado originalmente, también se extenderá.
Otro riesgo es que al no haber analizado los requerimientos puede llevar a implementar un proceso de una forma que no es la que más le conviene a la empresa, al tratar de ajustarlo de todos modos a lo que maneja el sistema.
- Designar como gestor del proyecto al Jefe o Encargado de TI
En un proyecto de implementación de un sistema nuevo, el Jefe o Encargado de TI y su personal, tienen tareas que ejecutar, las cuales se agregan a sus actividades cotidianas de operación, soporte y mantenimiento del sistema actual.
En la práctica, cuando se pretende que este personaje además, administre la ejecución del proyecto que contiene tareas responsabilidad del contratista, pero también del contratante, corremos el riesgo de que el manejo no sea objetivo e imparcial. Es decir, al ser juez y parte, se pueden tomar decisiones que favorezcan en un momento dado la posición del equipo de la empresa, más no necesariamente a la empresa.
Lo mejor es contratar a un consultor externo con experiencia que lidere al equipo de trabajo de ambas partes (contratista y contratante) y administre de manera equilibrada, especialmente el alcance, los cambios y los riesgos del proyecto. Esta experiencia le permitiría además identificar problemas con los procesos y recomendar mejores prácticas.
- Asumir que el proveedor del sistema es el único responsable de las tareas del proyecto
Este es un error muy común y es el que mayores desencuentros y malos entendidos genera. Si la empresa no está consciente de que tendrá tareas que son su responsabilidad, no tomará las previsiones para poder hacerles frente, en cuanto a recursos y tiempo se refiere. Es por ello, que el plan de trabajo hay que elaborarlo de manera conjunta, es decir, con la participación del contratista y el contratante.
- No designar un grupo de trabajo interno exclusivamente para las tareas del proyecto
Este es también otro error muy común causante de la mayoría de las dilaciones del proyecto. La empresa debe designar un equipo funcional y un equipo técnico a trabajar en el proyecto, cuya responsabilidad primaria, sea esa (trabajar en el proyecto). El primer equipo, que debe estar conformado por los conocedores más expertos de los procesos por área del negocio, serán los encargados de revisar el sistema junto con los consultores y validar que el mismo cumple con lo que se necesita. Deben ser personas abiertas al cambio, es decir, a adaptarse a nuevas formas de trabajar. El segundo, es el equipo que debe poder proveer al contratista de todos los elementos técnicos que se necesitan para que el sistema opere de manera correcta.
- Asumir que no se requiere un equipo técnico interno que conozca a profundidad el sistema que se está implementado
En el punto anterior, ya mencionamos la necesidad de un equipo técnico interno y su responsabilidad primaria en el proyecto. Este equipo también, debe prepararse lo suficiente para ser capaz de actuar como entrenador y primer nivel de soporte a los usuarios, una vez el sistema esté en marcha, y para atender necesidades de nuevos requerimientos de los usuarios, especialmente en reportes y consultas.
De otro modo, una vez concluida la implementación, la empresa crearía un nivel crítico de dependencia del proveedor del sistema, tanto para soporte como para atender nuevas necesidades, lo que puede poner en riesgo la operación de los negocios.
- Contratar desde el inicio todas las licencias de uso del sistema, sin conocer aún su funcionalidad
Cuando comercialmente el sistema se maneja con base a diversos tipos de licencias de uso, basados en las funcionalidades por área de negocio, es fácil equivocarse en cuanto a la cantidad de licencias que necesito adquirir entre las distintas variedades. En nuestra práctica profesional hemos visto que con mucha frecuencia, la empresa trata de adquirir todas las licencias desde el contrato original, pero en ese momento todavía no tiene una idea clara de toda la funcionalidad del sistema y quién debe utilizarla. Entonces quedan comprando más licencias del tipo que no necesitan y menos del que sí necesitan. Lo mejor es adquirir primero las que deberá utilizar el equipo de trabajo (funcional y técnico) y cuando ya ellos tienen un nivel de conocimiento adecuado del sistema, determinar cuántas licencias adicionales necesitarán de acuerdo a los usuarios y funciones que deberán ejecutar en la aplicación.
- Adiestrar al personal demasiado temprano
Este es otro error común y que trae luego mal uso del sistema. El adiestramiento de los expertos funcionales (aquéllos que forman parte del equipo del proyecto) debe darse desde el inicio del proyecto, mientras que para el resto de los usuarios debe hacerse en la fecha más próxima posible a la salida en producción del sistema. Y la razón es muy sencilla, si se hace muy temprano y el sistema no está listo en una versión de demostración para que puedan practicar, lo que aprendieron se les va a olvidar y previo a la salida en producción, habrá que repetir el entrenamiento. Recuerde que el adiestramiento debe ser una inversión, y en este caso la empresa puede llegar a perder la oportunidad de entrenar a los usuarios que verdaderamente van a utilizar el sistema. Esto último es una realidad, sobre todo en las empresas con alta rotación de personal. Se entrena un personal que se retira antes de que efectivamente tenga que hacer uso de esos conocimientos.
- Asumir que la migración de datos es tarea exclusiva del proveedor del sistema
La conversión de datos se refiere al proceso de ordenar, verificar, corregir, completar y traspasar los datos del sistema actual, a un formato soportado por el nuevo sistema, para terminar con la carga al nuevo repositorio. Y, una vez migrada toda la información, corresponde a validar y certificar que ésta se cargó en forma completa y correcta.
La preparación y verificación de los datos no puede ser responsabilidad de nadie más que de la empresa y la razón es simple, la empresa es la dueña de la data, no el proveedor del sistema. En estas tareas participan tanto el equipo de usuarios expertos, como el equipo técnico. Al primero le corresponde verificar, corregir y completar los datos actuales, y validar y certificar la data migrada; y al segundo, el desarrollo y pruebas de los programas de conversión.
Ahora bien, al proveedor del nuevo sistema también le toca una parte importante de este proceso. Nos referimos a la carga o migración, al nuevo repositorio de datos, de la data que ha preparado y entregado la empresa. Es el proveedor también, quien debe facilitar una metodología para que la empresa pueda llevar cabo la validación y certificación de la data migrada.
En resumen, la migración de datos es una tarea conjunta: la extracción y preparación de los datos es tarea de la empresa, la carga al nuevo sistema, es tarea del proveedor, y finalmente, la verificación y certificación de la data cargada, es responsabilidad de la empresa.
- Llevar a cabo, demasiado tarde, el análisis de las necesidades de integración con otros sistemas de la empresa
Esto aplica en los casos en los que la empresa tiene funcionando otros sistemas especializados como puede ser Gestión de Recursos Humanos, Pago de Planillas, Puntos de Venta, entre otros.
Determinar si se va a requerir compartir información entre estos terceros sistemas y el nuevo, debiera ser una tarea previa a la adquisición, pero si no se ejecuta antes, debe ser hecha lo más temprano en el proyecto. Es la única manera de que tanto la empresa, como el proveedor, puedan tomar las previsiones en cuanto a recursos (económicos, técnicos y de personal) necesarios para poder cubrir este requerimiento.
- Asumir que la empresa se adaptará a los procesos de negocio que ofrece el sistema sin necesidad de manejar el cambio
El uso de un nuevo sistema informático como apoyo a la realización de las tareas de las diversas áreas del negocio de la empresa, implica necesariamente un cambio en la forma como las cosas se están haciendo, es decir, un cambio en los procesos.
Es natural que haya resistencia al cambio porque nos saca de nuestro estado de confort y nos obliga a aprender y practicar nuevas formas de trabajo, que probablemente requieran de una disciplina a la que no estamos acostumbrados. Es por ello que es iluso pretender que no se necesita llevar a cabo una gestión del cambio que facilite esta adaptación.
Le interesa conocer más sobre el tema, escríbanos a info@infotechnology-con.net.
