Implantar un paquete ya no es lo que solía ser…

La parte más compleja de un proyecto de implantación de software es aquella relacionada con la gente que lo va a utilizar; con sus necesidades, sus expectativas… y su dolor. Si cuando se está implantando, los costos o el dolor actual superan los beneficios esperados, hay que revisar el proyecto.

La tendencia de la tecnología de información orientada a los negocios es minimizar la complejidad tecnológica de cara al usuario, y dejarla, tipo caja negra, para el uso exclusivo de los expertos que desarrollaron el paquete. De esta forma se evitan las complicaciones de tener que intervenirlo/modificarlo distorsionando su integridad. Quien haya desarrollado un paquete desde el diseño y la programación, sabe de lo que estoy hablando. Y quien haya sido usuario de un paquete desarrollado en casa, o de uno comprado, al cual se le hicieron cambios y adaptaciones, también sabe de lo que estoy hablando.

Los enfoques tradicionales de implantación de paquetes (o de cualquier tecnología de aplicación de software) tienden a trivializar la participación, durante la etapa de proyecto, de quien finalmente será usuario de la tecnología. Y esto es así, pues fueron basados en la premisa de que el paquete debía adaptarse a la empresa, colocando mayor énfasis en lo tecnológico e ignorando la mejora de los procesos y funcionalidades del negocio, beneficiario final del proyecto.

Los nuevos enfoques asumen que la empresa debe adaptarse al paquete, pues se supone que la tecnología está suficientemente depurada e incluye plantillas con procesos que ya incorporan mejores prácticas de negocio; de alguna manera se está comprando reingeniería, permitiendo que el mayor peso se coloque en el proceso de negocio y en la funcionalidad.

Por eso, uno de los errores más frecuentes que se sigue cometiendo es considerar una implantación como netamente tecnológica, cuando en realidad el contenido de procesos y relaciones humanas es sustancialmente más fuerte y de mayor riesgo/impacto. Ya sea que la reingeniería venga con el paquete, ya sea que haya que desarrollarla.

La empresa que no considere que el verdadero factor crítico de éxito en una implantación está en la gente, está condenada a que los proyectos no le salgan bien, ni en tiempo ni en costo; y ni aun en calidad.

En todo caso, invito a que se haga una encuesta a nivel de usuarios de paquetes implantados en los últimos tres o cuatro años, y estoy seguro de que los resultados serán de mayor insatisfacción en aquellos casos en los que se dejó la parte humana (gerencia del cambio) para después, o no se consideró en ningún momento.

En cuanto a los niveles de reingeniería que traen incorporados los paquetes, cabe mencionar que para nuestra región latinoamericana, hay que hacer trabajos de adaptación importantes, pues no toda empresa está bajo ISO-9000, ni cuenta con los niveles de tecnología y disciplina que se supone deben tener; además de no contar (a veces por no poder pagarlo) con el personal certificado para consolidar el éxito de la implantación.

Uno puede separar los componentes de un paquete, de cara a quien lo va a utilizar, en:

• El componente de datos.
• El de la aplicación en sí mismo, y
• El de las pantallas que se ven (front end).

Y en este último, que es el que utiliza la gente, debe estar el gran esfuerzo al momento de implantar, pues en la parte tecnológica de la aplicación en sí misma, usualmente hay tal nivel de parametrización y de trabajo previo del proveedor del software, que al momento de implantar sólo se requieren comandos para adaptar el ambiente de procesamiento y comunicaciones; el \»sólo se requieren\» del párrafo anterior no pretende minimizar de ninguna manera la importancia de este componente.

El primer elemento, el de los datos, si bien no tiene complejidad de implantación, se convierte en una actividad importante, por aquello de la confiabilidad y representatividad de la información histórica, la cual repercutirá en la calidad de la información para tomar decisiones, fin último de todo el esfuerzo. Debería preverse desde el principio del proyecto de tal manera que nunca pase por la ruta crítica de la implantación.

Desde siempre se ha planteado la dicotomía entre implantación gradual y aquella llamada \»big bang\» o implantación rápida. Ambas tienen sus ventajas y desventajas, las cuales surgirán del ambiente propio de cada empresa. Se puede comparar con una cirugía masiva para un ser humano. Y la pregunta es si ese cuerpo en particular será capaz de resistir ese tipo de intervención. O si por el contrario debe hacerse en forma escalonada, de manera tal que en un cierto horizonte haya un resultado exitoso.

En cuanto a la organización del proyecto, es recomendable que el líder de la implantación sea alguien proveniente de las áreas de negocio y con un alto nivel de prestigio y credibilidad. Una manera de darse cuenta de si la persona elegida es la correcta, es el nivel de quejas de sus jefes por haberlo asignado al proyecto siendo una persona tan valiosa. Si no hay quejas, algo no está bien.

Hay que evitar las implantaciones de laboratorio; esas en las cuales la gente de sistemas se encierra con un par de usuarios, lo hacen todo, y después lo muestran ya terminado. Hay que hacer participar, en forma comprometida, desde el principio a quienes usarán el sistema. Si en una empresa, es el departamento de sistemas o informática quien está liderando la implantación, recomiendo revisar el proyecto y asegurarse un rol preponderante para la gente del negocio.

La experiencia me ha enseñado que no hay dos empresas iguales, ni hay dos zonas geográficas iguales dentro de una misma empresa, de cara a una implantación de software. Y no hay tampoco dos departamentos iguales. Por consiguiente, los enfoques de implantación tampoco pueden ser iguales. La linealidad del enfoque de implantación, podrá parecer mas barata al principio, pero resultará mas cara al final. Hay que mantener un balance adecuado para que la inversión agregue valor en vez de problemas y frustraciones.

En términos generales, recomiendo tener en cuenta los siguientes aspectos:

• Construir un plan de trabajo que permita \»visualizar\» el producto final. El nivel de detalle y la coherencia y secuencia de las actividades deben ser “fáciles” de interpretar por el lector del plan. Si uno debe explicar que \»cuando digo esto, quiero decir lo otro\», seguramente hay un problema de \»visualización\» en el plan.
• No durar más de cinco (5) meses implantando. Después de ese tiempo, comienza un desgaste tal, que debe ser identificado, compensado e incluido formalmente en el plan. Una manera de manejar proyectos largos/grandes, es separarlos en proyectos menores que comprendan áreas de impacto y resultadsos claramente diferenciadas.
• Mantener la relación costo actual/beneficio futuro en un punto controlable que evite que el proyecto se convierta en un problema.
• Desarrollar un análisis de riesgo que identifique las fuentes, los conceptos, sus impactos y las acciones necesarias para compensarlo. El riesgo tecnológico debe ser una consideración importante.

Uno debe poder pararse al final del proyecto, mirar para atrás en el tiempo y poder decir que fue exitoso. La otra opción, parados en el mismo sitio, es dar explicaciones de por qué aún no está terminado, por qué nadie lo usa, por qué todos lo critican, por qué salió mal, etcétera, etcétera.

Afortunadamente, implantar un paquete ya no es lo que solía ser; pues ahora lo verdaderamente importante es que quien lo vaya a utilizar participe activamente y se sienta “dueño” del proyecto.