Aunque parezca una decisión “técnica”, sus consecuencias son muy importantes por lo que no debe dejarse de lado como una “característica técnica más”. Estamos hablando del “contenedor” de todos los documentos y una elección incorrecta puede poner en peligro el funcionamiento de la empresa por lo que su elección no debe responder únicamente a criterios técnicos.

Sin ánimo de ser exhaustivo, me gustaría recorrer las diferentes posibilidades que encontramos en el mercado y analizar sus principales ventajas e inconvenientes. Estoy seguro que este sencillo ejercicio será suficiente para tomar una decisión bien fundada o, al menos, servirá para descartar algunas opciones rápidamente.

Empecemos por lo más sencillo: guardo mis documentos como archivos en Windows (o Mac) dispersos por carpetas en los ordenadores de cada usuario. Obviamente esta forma de guardar los documentos no tiene ningún sentido (en un ámbito profesional) porque no ofrece las mínimas garantías de seguridad, no permite hacer copias de una forma sencilla y segura y resulta casi imposible localizar un documento concreto, a no ser que Pepe, María o Juan se acuerden casualmente dónde lo guardaron. Lo cito simplemente para que tengamos claro qué problemas esperamos que nos resuelva un buen programa de gestión documental.

El siguiente paso sería guardar estos documentos, ficheros, en un servidor único al que acceden los usuarios. Es un paso adelante. Simplifica muchísimo la creación de copias de seguridad y aumenta las posibilidades de encontrar un documento cuando vaya a buscarlo. Sigue pendiente un sistema de búsquedas eficiente y aunque posibles, las copias de seguridad requerirán un programa que controle los cambios, añadidos, eliminaciones… para que sea eficiente. Para cientos de documentos, a lo sumo unos pocos miles, y pocos usuarios puede funcionar. Pero no resistirá si aumente el volumen (de ficheros o usuarios).

Tercera opción: un programa de gestión de ficheros (me resisto a llamarlo “gestión documental”) que permite clasificarlos con una estructura más o menos sencilla. Mantiene los documentos como ficheros de Windows (o Mac, ya no lo repetiré más) y resuelve o mejora las búsquedas. No resuelve, en absoluto, el problema de hacer copias de seguridad de los documentos (ficheros dispersos) ni el acceso a ellos. No deja de ser un juguete para pocos documentos. Nada más.

Cuarta posibilidad: por fin, una base de datos para almacenar los documentos. En realidad debería haber empezado por aquí. No tiene sentido hablar de gestión documental “en serio” si no hay una base de datos gestionando los documentos. Así que, empiezo de nuevo la numeración porque hay varias opciones.

1.- Base de datos “propietaria”. Aunque parezca mentira, hay empresas que ofrecen sus productos sobre “su” propia base de datos. Digo que parece mentira porque esta situación la vivimos hace 20 años con los sistemas operativos y el hardware y parecía que se había acabado ya. A muchos, no solo a mí, nos sorprende que haya empresas que utilizan su propia base de datos para conservar y gestionar documentos. Casi tanto como si no utilizasen un sistema operativo “estándar” como Windows, Mac o Linux. Sin embargo, ahí están. Existen. Y tienen, algunas empresas, buenos productos. Me cuesta encontrar “pros” a esta forma de archivo. Es evidente que para estas empresas su producto es estupendo y lo conocen a la perfección, ya que ellos lo han desarrollado. Pero igualmente puedes conocer muy bien Oracle o SQL server. Pueden decir que son robustas, pero ¿más que Oracle? Creo que la única ventaja posible puede ser el precio. Y, sin embargo, inconvenientes le encuentro muchos. Robustez, calidad, seguridad… ¿Pueden compararse con los “monstruos” de las bases de datos que llevan 20, 30 ó 40 años instalando millones de gestores de datos por todo el mundo? Y, por encima de todo: ¿qué pasa si tienes un problema con tu proveedor, con esta empresa? ¿Cómo accedes a tus documentos, guardados en un sistema que nadie, nadie, conoce salvo ellos? Realmente me cuesta imaginar que sea razonable instalar un programa de gestión documental sobre una base de datos propietaria.

2.- Base de datos “estándar”. Con “estándar” quiero decir que sea un producto conocido, con muchos años de vida, del que hay manuales, documentación, cursos… del que puedes encontrar un técnico en cualquier lugar del mundo. En esta categoría, que puede parecer restrictiva, hay muchos productos. Por citar alguno: DB2, Firebird, Informix, Interbase, MySQL, Oracle, PostgreSQL, Pervasive, SQLite, SQL Server, Sybase… Todos estos tienen una característica: se basan en el lenguage de consulta estructurado SQL que es tan, tan estándar, que no creo razonable salirse de él. Ya tenemos un grupo ganador. Aunque dentro de esta lista haría 3 grupos:

2.a.- Las de software libre: MySQL es, creo, la más representativa o conocida.

2.b.- Oracle y SQL Server (de Microsoft): las más extendidas, de largo. (Tanto que ya escribí hace tiempo sobre ellas).

2.c.- El resto. Algunas como DB2 casi tan conocidas como Oracle, pero propiedad de IBM, dirigida a grandes empresas y, por tanto, mucho menos extendida que Oracle o SQL server. Otras han tenido su momento de gloria, o tienen su nicho de mercado, pero su popularidad no tiene comparación respecto a las dos anteriores.

Para empezar, descartaría el tercer grupo, ya que en este blog hablo de gestión documental para PYMES.

Me quedo, por fin, con 3 finalistas. Tanto Oracle como SQL Server o MySQL tienen las características que considero IMPRESCINDIBLES para un programa que vaya a instalar en una empresa: son muy, muy conocidas, hay técnicos expertos en su manejo en cualquier sitio y son muy robustas y escalables. A partir de ahí, la discusión de si una es mejor que otra en tal y cual punto es irrelevante: cualquiera de ellas es más que suficiente para manejar mis cientos de miles de documentos sin problema. Un software de gestión documental “basado” en cualquiera de las tres será bueno o malo por sí mismo, pero no por la base de datos que utiliza.

Por mi parte, si eres lector habitual ya lo sabes, me gusta más Oracle, probablemente porque es la que mejor conozco. Pero no descartaría un programa que utilice alguna de las otras dos. Eso sí, asegúrate de que la empresa que te instale el software te da las claves de acceso a los datos. Si les toca la lotería y desaparecen o simplemente te peleas con ellos porque te suben el precio del mantenimiento, tener un acceso directo a los documentos es un seguro de vida.

Nota: en todas las entradas de este blog, y en ésta en particular, utilizo “empresa” para referirme a la organización que instala o piensa instalar un sistema de gestión documental. Puede ser una empresa, pública o privada, un despacho profesional, una consulta de un médico o una Administración Pública, ya sea un ayuntamiento o un departamento de un ministerio o una Universidad. Incluso una persona solamente (aunque con muchos documentos). Utilizo la palabra “EMPRESA” por economía del lenguaje. Espero que no haya que respetar la “paridad” en este caso y los lectores de organizaciones que no son una empresa no se sientan discriminados.

Pero si hablamos de gestión documental, la cosa cambia.

Ahora un “registro” de la base de datos, cada uno de los elementos que la componen, es un fichero. Puede ser un documento con texto de Word (20, 30, 140Kb…), PDF (50, 100, 200Kb), Excel (otro tanto)… pero puede que tengamos imágenes, logotipos, fotos, documentos escaneados con una buena resolución… con lo que ya el orden de magnitud empieza a ser de Mb, más que Kb. No es difícil que un usuario incorpore 2 ó 3 mil documentos al año con lo que nos empezamos a mover (en una PYME de 10 usuarios) en cifras de varios Gb anuales. Esto ya no es tan fácil de gestionar. Y mucho menos sencillo es garantizar un rendimiento adecuado al introducir los nuevos documentos, y al consultar los existentes. Ya no me vale una base de datos tipo Access: necesitamos algo “serio”.

Ahora que ya he decidido lo que quiero, la pregunta de siempre: ¿cual elegir? Porque, como pasa con todo en la sociedad actual, la oferta es enorme, variada y con frecuencia contradictoria. Sin ánimo de ser exhaustivo, no tengo espacio ni vocación de serlo aquí, ahí van unos comentarios sobre cómo y porqué elegimos nosotros la base de datos sobre la que “montar” nuestra aplicación ArchivaTech. (En realidad, más correcto es decir SGBD, sistema de gestión de base de datos, pero es muy largo) .

Primera decisión: software libre o propietario. ¡Ya estamos otra vez! Y es más complicado aún, porque puedes montar un programa desarrollado con un lenguaje “propietario” como Delphi o Visual Basic, sobre un SGBD libre, o no, y, a su vez, sobre un servidor con Linux o Windows Server, por ejemplo. Un pequeño rompecabezas.

Pero centrémonos en la base de datos (SGBD), solamente:

“Libres” o gratuitas hay varias: MySQL, PostgreSQL, Firebird, SQLite… las dos primeras son las más conocidas y, sin duda, son válidas para un proyecto, por complicado que sea.

“Propietarias” hay muchas más. Dejando de lado las menos “potentes”, dBASE (un clásico, pero muy superada), FileMaker, Interbase, Access… tenemos las 2 más conocidas, Oracle y SQL Server de Microsoft, además de IBM DB2, Informix, Progress… que es raro verlas en PYMES.

Y hay un tercer grupo, las “super-propietarias”. Las creadas por empresas, normalmente pequeñas, a medida para su programa de gestión, documental o no.

¿Cual elegir? La respuesta es muy sencilla: todas sirven. Todas. Esto ya está inventado. Cualquiera de ellas es válida, si se configura y utiliza bien. La decisión no es en función de que sirva o no para mi necesidad. Seguro que te sirve. La decisión estará basada en otras características.

Nuestra decisión, que no consejo: usamos las 2 más conocidas, Oracle y SQL Server. La que más nos gusta es Oracle. Es muy, muy potente. Es muy, muy conocida, es decir, siempre tienes alguien a quien preguntar, además de a los propios técnicos de Oracle. Tiene un programa de partner y desarrolladores con miles y miles de páginas de ayuda técnica. Y no es cara, pese a su fama. Una instalación de 5 usuarios sale por unos 70€ por usuario (en una aplicación “embebida” como es ArchivaTech). Y tiene TODO lo que puedas necesitar. Tambien tenemos alguna aplicación en SQL Server, que no va mal. La decisión en este caso venía forzada por el cliente. Pero, vuelvo a lo de antes, las dos sirven.

Evitamos las “exóticas” (en PYMES, insisto, como Progress, Informix…) porque es mucho más difícil conseguir ayuda técnica cuando tienes un problema. Un argumento definitivo para los programadores.

Y, ahora sí es un consejo, me parece un error montar un programa de gestión documental sobre una base de datos “super-propietaria” de una empresa pequeña. ¡Te acabas de casar con ellos para siempre! Si nos toca la lotería y cerramos (no suele ocurrir), nuestros clientes tienen sus datos en Oracle. ¡Cualquier técnico les puede recuperar la información mientras nosotros estamos en el Caribe! Pero si te peleas con tus proveedores de una base de datos propia, suya, ¿qué pasa con los datos? Hay un riesgo que creo que es innecesario correr.

En cuanto al software libre, es casi una decisión filosófica. Es como ser usuario de Mac, o tener un iPhone. O como convencer al que tiene una Canon reflex fabulosa de que las Nikon son mejores. ¡No hay nada que hacer! Sin duda, el software libre es una decisión válida y técnicamente irreprochable. Y lo es, igualmente, montar Oracle. Hay espacio para todos y hay aplicaciones estupendas en los dos sistemas. No van a ser mejores o peores los programas, ni los usuarios van a trabajar mejor, por el hecho de haber elegido uno u otro gestor de base de datos. La clave está en el software, en el interfaz de usuario, en la facilidad de uso, y eso es independiente de la tecnología.