3 decisiones a evitar en el diseño de tu gestor documental

Los gestores documentales son como los coches.En el caso de los coches, cualquier coche que compres, te va a permitir desplazarte. Así mismo, cualquier gestor documental que adquiera tu compañía, os va a permitir almacenar documentos. Pero al igual que en el caso de los coches, los usuarios del software no suelen querer el coche como viene de fábrica, sino que quieren customizarlo de acuerdo con sus requerimientos.

Algunos usuarios optarán por las customizaciones que les permite la marca, lo que les garantiza que dichas customizaciones están bajo garantía: color de la pintura, kit de faros antiniebla, asistente de parking delantero, sistema de navegación, etc.

Otros usuarios querrán hacer customizaciones complejas: ¡Incluso tocar el motor!

Hacer cambios sobre lo que viene de fábrica con el gestor documental y más allá de las propias customizaciones que el software permite, presenta dos riesgos importantes:

• Pone en riesgo la viabilidad del proyecto: puede que se estén pidiendo cambios tan complejos de realizar, que extiendan de forma inesperada la duración del proyecto o, que incluso, lleguen a hacerlo irrealizable.
• Pone en riesgo la capacidad para mantener el software: es posible que tengamos dificultades para actualizar el producto a nuevas versiones por incompatibilidades con los desarrollos a medida.

A continuación, compartimos con vosotros 3 errores especialmente nocivos que debes evitar si estáis al frente de un proyecto de gestión documental que implica customización de el software.

1. Evitad hacer un Frankenstein de funcionalidades

Un coche es un coche. No sirve para cortar el césped, por lo que añadirle un cortacésped tiene poco sentido ¿verdad? Pues igual con un gestor documental. ¿Por qué insistimos en que el gestor documental haga cálculos o tenga funcionalidades propias de un ERP?

He participado en procesos incluso en los que te piden que el gestor documental sea capaz de ¡calcular la pureza de una muestra de laboratorio!

Mantén la funcionalidad del gestor documental y utiliza integraciones con otras herramientas para cubrir necesidades específicas que tengas.

2. Desarrollos de medida

Permitidme que cambie de símil para ilustrar este punto. Seguramente, si encarguéis con un sastre un traje a medida, os salga más caro que ir a una tienda como Zara y compraros allí un modelito.

Con el software pasa lo mismo. En este caso, los mayores costes se pagan a medio y largo plazo. Una aplicación desarrollada por nosotros o sólo para nosotros, tiene varias desventajas:

• Se testea y evalúa por un grupo reducido de usuarios. Un producto de mercado, es probado y evaluado por usuarios en una mayor variedad de circunstancias, por lo que el software se encuentra mucho más depurado.
• Suelen quedarse desactualizadas. Al no existir un producto de mercado detrás, todas las actualizaciones corren a vuestro cargo. Ya sea con personal interno o externo, tendréis que asumir los costes de evolucionar la plataforma.
• Problemas de rendimiento. Como os comentaba, las aplicaciones de mercado son probadas por muchos más usuarios en condiciones diversas, entre ellas, volumetrías de documentos o usuarios concurrentes que vosotros no tenéis de momento, pero que con el paso del tiempo, pueden ser las vuestras. Los fabricantes de software realizan pruebas con incluso billones de documentos, en algunos casos, de modo que vuestro volumen de documentos no sea un problema.
• Problemas de integración. Si desarrolláis una aplicación a medida, también tendréis que desarrollar sus posibilidades de integración. No hay producto de mercado en la actualidad que no cuente con una API. Muchos productos de mercado soportan CMIS o incluso tienen funcionalidad embebible.

Los problemas anteriores, aplican también para desarrollos grandes que decidamos hacer sobre un producto de mercado, lo cual nos remite de nuevo al punto 1.

3. Demasiadas restricciones, validaciones o campos que amenacen la usabilidad de la plataforma

Este es un error fácil de cometer. Os pongo algunos ejemplos típicos de algunos requisitos técnicos de proyectos de gestión documental:

• Formularios con más de 25 campos, 90% de ellos obligatorios. Los usuarios se desmoralizan ante formularios tan extensos. ¿Realmente necesitamos toda esa información?¿No hay posibilidad de heredarla o importarla en lugar de digitarla?
• Campos que ponemos como requeridos y que bloquean al usuario a la hora de continuar si no están completos. Usualmente, los que diseñan el software, tienden a olvidar que hay excepciones. Que no siempre se contará con todos los datos, y que los usuario NO se pueden quedar bloqueados si les falta un dato.
• Comprobaciones de formato que bloquean al usuario si no se cumplen. Caso idéntico al anterior. Por ejemplo, no dejamos enviar un formulario si un dato no tiene un determinado formato. Al principio, pensamos que el formato es X, pero en el futuro nos damos cuenta de que en algunos casos es también Y. Llegados a este punto, para los casos de formato Y, los usuarios se encuentran bloqueados.
• Ocultar campos de acuerdo a reglas de negocio. Este es otro requerimiento típico que le gusta mucho a los usuarios en la fase de diseño. El problema con esto es parecido al de los dos puntos anteriores. Cuando ya estamos en producción con el nuevo software, nos damos cuenta de que estamos mezclando reglas y nos quedamos sin visibilidad de campos que necesitamos o, nos damos cuenta de que no en todos los casos la regla de ocultar datos debe cumplirse.
• Demasiado Javascript. Los últimos dos puntos descritos, suelen controlarse en las aplicaciones mediante código Javascript. Si se meten muchas validaciones o reglas de negocio, terminamos con código JS difícil de mantener. Además, cualquier olvido que hayamos tenido, nos va a significar tener una dependencia técnica para solucionarlo.

Estos son sólo algunos ejemplos que me vienen a la cabeza, pero hay muchos mucho más casos y errores.

Confiad un poco más en el usuario, en su profesionalidad y en su capacidad de discernir, antes de decidir ponerle todo tipo de trabas que le desmotiven a la hora de usar el nuevo software.Pensad también, que por más que queráis, en el momento del diseño, no váis a tener en mente todos los posibles casos y excepciones que pueden darse. Lo mejor es ofrecer visibilidad y muchas ayudas de consulta para los usuarios que les sirvan de referencia.

Espero que os sirva de orientación y reflexión si os encontráis en la fase de definición de un requisito de un proyecto nuevo o ampliación de gestión documental.