Hace unos cuantos años, durante la etapa de estabilización de un importante proyecto, sucedió una situación complicada, una caja con un faltante significativo, sospecha de dolo, puertas que se cerraron y llamada a la comisaría.

 

Horas de tensión, personas llorando, desconfianza entre compañeros, auditores hurgando entre papeles, en fin, caos.

 

Cuando nos enteramos, preguntamos tímidamente si habían verificado en el sistema los saldos de caja… a nadie se le había ocurrido. Cuando lo hicieron, la sorpresa fue que el arqueo de la cajera coincidía con los movimientos registrados y no había diferencia.

 

¿Qué había sucedido? Que la supuesta diferencia de caja se daba contra una planilla manual que el Tesorero llevaba ‘porque no confiaba en el sistema, sino en su forma de hacer las cosas’

 

Resultó que, durante la jornada, la cajera había hecho una remesa a la Tesorería, que registró según el procedimiento, pero el Tesorero no registró en su planilla, fueron a los comprobantes, encontraron la remesa firmada por ambos y todos felices.

Mientras nos llegaban las felicitaciones porque el sistema había aportado la solución al problema, nos quedaba un retrogusto amargo, no habíamos logrado que el Tesorero confiara en el sistema.

 

Esa enseñanza nos acompaña desde entonces, y así la incorporamos al proyecto, traducida a procedimientos, hitos de control, actas de cumplimiento, etc.

 

En nuestros relevamientos de preconfiguración, incorporamos la pregunta ¿para qué se hace?, inmediatamente después del ¿qué se hace?, no importa que sea una tarea que el sistema la prevea de otra forma, o en otro punto del proceso, lo que importa es que el consultor de campo entienda cuáles son los puntos de control que tiene que demostrar al usuario que quedan cubiertos y le den seguridad.

 

Luego, en la validación, el objetivo es que el usuario, reproduciendo en el sistema, las tareas periódicas, -todas las tareas- obtenga por lo menos la misma información que usaba antes, con el valor agregado de las mejores prácticas, el uso de datos ingresados previamente, el aporte de su tarea al sistema integrado y al resultado final.

 

En esta negociación con el usuario final, no se debe imponer, se debe convencer.

Con capacitación, involucramiento, participación en las decisiones, dominio técnico del asunto y explicación clara y contundente de porqué el sistema le cambia su forma de trabajo ‘que siempre se hizo así’.

 

Participación en equipo, con los usuarios que entran al sistema antes y son proveedores de información y con los que esperan como insumo, su aporte, para continuar con el proceso, es decir sus clientes.

 

Concluyendo: un sistema modelado eficientemente, especificado sin baches, desarrollado exactamente de acuerdo a la especificación, configurado con todas las funcionalidades disponibles, testeado hasta lo absurdo, sin un usuario final convencido y sintiéndose partícipe del producto final, no cumple los objetivos de implementación.

 

En todos los proyectos, nos encontramos con usuarios ‘claves’, con los que la negociación se torna más ardua, pero eso da para otra charla.