Andrés Pimentel.

Para escribir acerca de un “proyecto de automatización exitoso”, hay que definir primero a qué nos referimos con “exitoso”. Revisando la literatura, se encuentran variadas definiciones, donde la más tradicional es que un “proyecto exitoso” es el que se ejecuta dentro del plazo, presupuesto, calidad y cumple con los requisitos especificados en el alcance.

Pero, ¿qué pasa con un proyecto que según la definición anterior es exitoso, pero que una pequeña modificación -posterior a su implementación- se hace difícil y costosa? Más aun, y ya en el ámbito de la automatización, ¿qué pasa con los proyectos donde su programación es cerrada y no escalable, pero cumple con los cánones tradicionales de “proyecto exitoso”? La discusión puede ser larga y no es motivo del presente artículo, por lo que, a la definición tradicional, añadiré que el proyecto, además, debe dar una solución sustentable y escalable a las necesidades de la empresa que dieron origen al proyecto.

Dada esta definición, existen una serie de puntos claves a considerar en las distintas etapas de un proyecto de automatización. Es difícil abordarlos todos, pero, utilizando la experiencia, se identificarán y abordarán los puntos que frecuentemente se encuentran descuidados en la industria y que tenerlos en cuenta puede marcar una diferencia. Además, estos puntos presentados corresponden a la etapa de integración del sistema.

Es común encontrar en proyectos una definición vaga de los requerimientos, argumentando que el integrador conoce el proceso o existe experiencia al respecto. Una definición clara por parte del dueño del proceso es un punto de partida clave para el proyecto, y mientras más detallado, mayores son los beneficios tanto en términos económicos como de plazos.El no tener un alcance y objetivo claros hace que la mayoría del tiempo y los recursos se utilicen en tareas equivocadas.

El consejo es: obtenga los requerimientos técnicos y funcionales, no los salte, incluso si la empresa piensa que sabe lo que quiere, e incluso si Ud. piensa que sabe lo que quieren. Hágalo y asegúrese de tener los requerimientos técnicos y funcionales correctos.

Una especificación funcional describe lo que el sistema entregado debe hacer, similar al contrato del proyecto pero con mucho más detalle. Es importante que establezca con el mayor nivel de detalle cómo será la aplicación final, definir estándares a utilizar, arquitectura de control, definición de pantallas, sistemas de seguridad, descripción del sistema de alarmas, y, lo que considero el documento más importante: la filosofía de control. Estas especificaciones muchas veces son entregadas en una ingeniería de detalles, pero si no se cuenta con ellas, se deben realizar como primera actividad del proyecto. Además, la tendencia hoy en día es integrar todos los sistemas de la empresa, por lo que si el proyecto se debe integrar con sistemas superiores, se debe definir además el intercambio, recolección y reporte de datos.

Las especificaciones deben pasar por aprobaciones del cliente con el objetivo de que quede plasmado y acordado lo que este espera del proyecto y lo que el proveedor realizará.

Es común encontrar clientes con sistemas que prácticamente son una “caja negra”, con documentación incompleta y una programación ejecutada según el programador de turno, lo que provoca grandes dolores de cabeza cuando la aplicación falla o se necesita modificar, ya que dependen de una persona en particular. Para evitar lo anterior, se recomienda que el desarrollo de las aplicaciones siga siempre un estándar. En primer lugar, se debe utilizar el estándar del cliente, y si este no posee uno, se debe programar siguiendo las recomendaciones de los estándares internacionales. Además, la empresa integradora debe poseer su propio estándar de programación, buscando que el conocimiento quede en las empresas y no en las personas.

En tanto, la documentación debe ser realizada en paralelo al desarrollo. Es común que cuando los plazos de entrega se acercan, se deje de lado la documentación, pero en ese momento hay que recordar que un programa bien documentado ahorra importantes tiempos en las fases de implementación y soporte, los que siempre son mayores a los tiempos “economizados” por no documentar.

Por último, es primordial contar con una sólida prueba FAT. Este plan de pruebas se debe desarrollar en base a la especificación funcional. Las pruebas deben simular tanto la operación normal como el sistema operando bajo estrés. Una práctica que trae buenos resultados es simular los estados de cada uno de los equipos, lo que posteriormente puede ser utilizado como herramienta de entrenamiento para los operadores.

Para nadie es desconocido que la planificación es fundamental para una buena puesta en marcha, y debe incluir desde los recursos técnicos a temas logísticos básicos para el equipo de trabajo.

Idealmente, el equipo de trabajo -elemento fundamental para este procesodebe estar conformado como mínimo por un programador, un electricista, un mecánico, el dueño del proceso y los operadores. Así, la detección y diagnóstico de cualquier problema será rápida y de resolución más efectiva y duradera.

Además, es un importante evento de capacitación para el equipo del cliente. En esta etapa, la participación de los operadores resulta un elemento inapelable, ya que les permitirá conocer el sistema tanto en operación normal como operando bajo estrés.

Por más automatizado y bien implementado que esté un sistema de control, no podrá alcanzar su rendimiento óptimo si el personal que lo opera o mantiene, no lo conoce o no sabe cómo utilizar las herramientas que el sistema le entrega. Los operadores y mantenedores son una pieza clave en el funcionamiento del sistema, por lo que la capacitación es una etapa que no puede ser dejada de lado o menospreciada y debe ser ejecutada con la importancia que le corresponde.