Eligiendo un producto de gestión documental (1/2)

 

480px-Bowl_of_Hygeia_and_serpent_and_scales  Periódicamente surge en distintos ámbitos (listas de distribución, grupos, foros, ..) preguntas como ¿Cuál es el mejor gestor documental? ¿Qué producto me recomendáis?, … Este planteamiento es un error que nos puede salir caro (literalmente en muchos casos). La elección debe ser un proceso, más o menos largo o costoso según el tamaño o previsión del uso, pero siempre un proceso organizado y sobre todo medido.

Si trasladamos la pregunta a otro escenario, se puede ver rápidamente los problemas. Si se pregunta ¿Qué vehículo me recomendáis?, pueden surgir las dudas ¿Para reparto comercial o para ocio? ¿Para una familia o para una persona? ¿Para usarlo en el campo o en la ciudad? ¿Para viajar 5.000 km/año o 30.000 km/año?.

Lógicamente, según las necesidades y requisitos puede ser más adecuado un producto u otro. Si no se formaliza todos los requisitos, no podemos hacer una elección adecuada. Al igual que no existen coches pequeños por fuera y grandes por dentro, que consuman poco y sean muy potentes, con acabado de lujo pero muy baratos,.. no existen productos mágicos. Elegir un producto significa previamente elegir requisitos. Y es muy importante destacar la palabra “elegir”.

Para similares circunstancias, un usuario o grupo puede dar más importancia a unos requisitos que a otros. Incluso con todos los factores similares, incluyendo consumo, puede elegirse un modelo de automóvil que emita menos gases contaminantes, o preferirse un vehículo que requiera menos revisiones, aunque cuesten más cada una.

Puede surgir la tentación de pensar “pero un proceso de selección solo es aplicable a una empresa grande, en otros casos no se justifica”. Esto puede comprobarse con unos simples números. Vamos a suponer que elegimos un producto para usarlo solo 4 años, que lo utilizarán solo 5 personas solo 2 horas al día. Despreciamos las diferencias de costes (licencias, formación, infraestructura, parametrización, desarrollo) y nos centramos solo en el tiempo empleado para su uso (usuarios, administradores, desarrolladores). Si las diferencias de rendimiento entre 2 alternativas son de solo un 5%, una opción implicará 4*5*2*220 = 8.800 horas y la otra opción, un 5% menos = 440 horas menos (casi 3 MESES).  Así que dedicar 2 o 3 semanas a elegir un producto no parece descabellado, incluso para un escenario tan reducido como el expuesto, ya que nos podemos ahorrar 3 meses de trabajo. Si pensamos en diferencias mucho mayores entre alternativas y en volúmenes más grandes de usuarios, los ahorros son mucho mayores, así que parece obligado invertir tiempo para poder ahorrarlo posteriormente. Eso sin contar problemas como la (falta de) disponibilidad, la carencia de funciones necesarias o la imposibilidad de configurarlo para que funcione como necesitamos.

Una vez vista la conveniencia de un proceso de selección, vamos a repasarlo de forma resumida. Las posibles etapas a incluir  serían:

  • Definición Requisitos.
  • Selección de candidatos.
  • Valoración.
  • Piloto.

 

Definición Requisitos.

Esta es la etapa más importante con diferencia. En ella debemos definir qué estamos buscando y, en caso de no encontrar la opción perfecta, cuáles son nuestras preferencias. Como se ha  visto antes, no basta decir “Solo busco un gestor documental”, se debe detallar exactamente todo lo que se pide al producto y cómo va a utilizarse.

Es recomendable agrupar los requisitos en varios bloques “temáticos” ya que facilita el análisis y permite que diversas personas rellenen los requisitos de su especialidad o los puntúen. Los bloques pueden ser, por ejemplo:

  • Funciones Básicas: Donde se incluirían las funciones básicas del producto, todas las funciones que se utilizarán el 90 % del tiempo.
  • Funciones Extendidas: Donde se incluiría módulos adicionales de extensión o poco utilizados.
  • Configuración y Desarrollo:  Funciones de parametrización y desarrollo para adaptarlo a nuestras necesidades y de integración del producto con otros sistemas. Esto incluiría posibilidades de definir tipologías documentales, ciclos de vida, conectores para integrarse con sistemas de otro tipo, lenguajes de desarrollo, etc.
  • Arquitectura/Administración: Evaluación de requerimientos técnicos como escalabilidad, rendimiento, alta disponibilidad, compatibilidad con productos o software ya instalado, posibilidades de expansión, administración, etc.
  • Seguridad: Aspectos relacionados con la seguridad, como autenticación de usuarios, autorización, mantenimiento de usuarios, encriptación de documentos, trazas de las operaciones, etc.
  • Fabricante/Difusión: Valoración de la difusión del producto y del fabricante para evaluar las posibilidades de soporte técnico o apoyo para formación o parametrización por parte del fabricante o de terceros.
  • Costes: Todos los costes de despliegue y uso del producto, esto incluye no solo las licencias, sino soporte técnico, infraestructura necesaria para su ejecución, software adicional, formación, parametrización, etc..

Para cada requisito es importante definir claramente qué se espera exactamente, y cuando sea posible, intentar definir los valores de las medidas para eliminar la subjetividad al poner una nota.  Como indicaba en mi texto anterior, hay muchas interpretaciones posibles (https://www.biblogtecarios.es/joaquinhierro/la-biblioteca-de-babel-o-como-sobrevivir-en-un-mar-de-siglas-y-terminos-de-gestion-documental/)

Ej. Criterios de puntuación: Definición de metadatos:

  • 0 – No puede definirse metadatos
  • 1 – Manejo de tipo Cadena-String
  • 2 – Además de tipo Fecha
  • 10 –  Además puede validarse metadatos contra listas de valores.

Con todos los bloques y requisitos definidos, llega el momento de “elegir”, de ponderar. Es necesario poner un peso a cada uno de los requisitos y bloques para poder obtener una nota de cada alternativa. Lo más recomendable es que en cada bloque, los pesos de cada requisito sumen 100%, y la suma de los bloques sume igualmente 100.

Esto dará lugar a una hoja de cálculo como:

Bloque Requerimiento Peso

Criterios de puntuación

Funciones Básicas 30%
Definición de metadatos

60%

Control de versiones

40%

Funciones Extendidas 20%
Requisito 3

40%

Requisito 4

30%

Requisito 5

30%

. . . . . . . .  . .

Es decir, la nota de “Funciones básicas” es un 30% de la nota total del producto. A su vez, la nota de “Definición de metadatos” es un 60% de la nota total del bloque “Funciones básicas”.

Es conveniente el puntuar sobre 100, porque esto muestra muy claramente los pesos y sobre todo fuerza a elegir. Si queremos dar más peso a un elemento, nos vemos obligados a bajar otro para mantener la suma en 100.

El resultado/entregable de esta fase será una hoja de cálculo con la lista de bloques, requerimientos de cada bloque, criterios de valoración y  pesos e cada elemento.

 

Selección de productos candidatos.

Una vez definido qué queremos, y la importancia que se da a cada factor, puede buscarse candidatos. Para ello contamos con

  • Las opiniones de colegas que pueden sugerir productos
  • las web de cada fabricante
  • Wikipedia  que no solo incluye las entradas sino comparaciones de productos,
  • las consultoras clásicas como Gartner y Forrester que tienen sus informes y “cuadrantes mágicos” sobre productos (aunque suelen ser de pago, en ocasiones están disponibles resúmenes o versiones anteriores para acceso público)
  • Y desde luego siempre puede buscarse en Internet (ojo, que además de EL BUSCADOR, existen otros buscadores (y pasarelas/aglutinadores) que, a diferencia de España, se utilizan bastante en otros países y pueden devolver resultados diferentes y/o en otro orden)

A partir de las diversas fuentes podremos hacer una selección de los que incluyen todos nuestros requisitos, o al menos la mayoría y los más importantes (con más peso). Es importante estar abierto a múltiples productos y no limitarse a los “clásicos”, pues puede encontrarse producto muy interesantes y en ocasiones bastante extendidos aunque poco conocidos. Muchos productos muy conocidos (tanto comerciales como OpenSource) tienen bastantes limitaciones, así que lo mejor es mirar objetivamente si cubren los requerimientos. Si por ejemplo es importante que su uso sea extendido, o que el fabricante sea de confianza, eso se verá reflejado en el peso que se asignó al bloque “Fabricante/Difusión”, pero es conveniente no autolimitarse de partida.

No obstante, en ocasiones puede haber requisitos imprescindibles, ya sea por requerimientos de la institución o por decisión durante el proceso (Ej. el producto debe instalarse sobre el sistema operativo X, ofrecer contrato de soporte in situ, utilizar la base de datos Y, etc..), que implicarían la eliminación automática de los productos que no lo cumplan.

El resultado/entregable de esta fase será una lista de candidatos, junto con toda la documentación recogida de cada uno de ellos, incluyendo comentarios o puntos de interés de cada uno.

En la segunda parte continuaré desarrollando el proceso….

Joaquín Hierro

Tras muchos años trabajando en software de gestión documental de diverso tipo, actualmente defino estrategia y elijo productos de gestión documental para una multinacional española. Mi colaboración en Biblogtecarios se orienta a analizar y difundir tecnologías y soluciones disponibles para un documentalista del siglo XXI.

5 respuestas a «Eligiendo un producto de gestión documental (1/2)»

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *