Cuando un sistema integrado de gestión de bibliotecas ya no basta

Estimated reading time: 9 minutos

En muchas bibliotecas, el sistema integrado de gestión bibliotecaria (SIGB) sigue cumpliendo perfectamente con buena parte del trabajo para el que se implantó. El catálogo está al día, la circulación funciona, las adquisiciones tienen su circuito y los ejemplares están controlados. Sin embargo, con los años han ido apareciendo otras piezas que también forman parte de la actividad diaria.

Puede haber un repositorio institucional, colecciones digitales, proyectos de digitalización, herramientas de descubrimiento, sistemas de autenticación, aplicaciones corporativas o herramientas específicas para determinados fondos. Algunas se entienden bien con el SIGB. Otras funcionan prácticamente por su cuenta.

Con el tiempo, esa convivencia se nota en tareas bastante concretas. Hay información que se introduce en más de un sitio, metadatos que no coinciden exactamente entre aplicaciones o ficheros que deben exportarse, corregirse y cargarse de nuevo. A veces una modificación hecha en un repositorio no llega al catálogo con la misma rapidez y una hoja de cálculo acaba resolviendo, de manera bastante artesanal, lo que los sistemas no intercambian entre sí.

Nada de esto implica necesariamente que el sistema integrado de gestión de bibliotecas (SIGB) haya dejado de funcionar. Puede ocurrir, sencillamente, que la biblioteca haya construido a su alrededor un ecosistema mucho más amplio que el que existía cuando se implantó.

La interoperabilidad entre todas esas piezas preocupa al sector desde hace tiempo y sigue sin estar completamente resuelta. NISO creó en 2025 un grupo de trabajo específico para estudiar cómo mejorar las integraciones abiertas entre SIGB, plataformas de servicios bibliotecarios y otras aplicaciones. Entre las cuestiones que está abordando aparecen la falta de estandarización, las limitaciones técnicas y la necesidad de intercambiar información en ambos sentidos.

El trabajo duplicado suele dar las primeras pistas

Conviene fijarse en qué hace el personal cuando la información tiene que pasar de un sistema a otro.

Si después de catalogar un recurso alguien tiene que volver a introducir parte de esos datos en un repositorio, ya hay una pista. También la hay cuando un proyecto de digitalización produce sus propios metadatos y, antes de utilizarlos en otra plataforma, hay que revisarlos, transformarlos o completar campos manualmente.

A pequeña escala estas tareas pueden pasar bastante desapercibidas. Una exportación semanal, algunas correcciones y unas cuantas altas duplicadas no parecen justificar una revisión tecnológica. Cuando crecen los fondos, los proyectos o el número de aplicaciones, la situación cambia. Las pequeñas intervenciones empiezan a ocupar tiempo y, sobre todo, hacen más fácil que existan versiones distintas de una misma información.

La Universidad Nacional de La Plata se encontró con un problema de este tipo al trabajar con producción académica procedente de distintos repositorios. La ingesta obligaba a resolver equivalencias entre esquemas de metadatos, identificar registros que correspondían al mismo recurso y tratar duplicados antes de incorporarlos.

Es un buen ejemplo porque muestra algo que a veces se simplifica demasiado. Mover datos entre aplicaciones no consiste únicamente en conseguir que el sistema A envíe información al sistema B. Hay que saber qué dato se considera válido, cómo se identifica el mismo recurso en dos lugares y qué ocurre cuando uno de ellos cambia.

Conectar aplicaciones es solo una parte de la integración

Dos sistemas pueden intercambiar registros y seguir teniendo problemas para trabajar juntos.

IFLA lleva tiempo señalando que la interoperabilidad tiene varias dimensiones. Además de poder transmitir información, los sistemas tienen que manejar estructuras compatibles y atribuir el mismo significado a aquello que intercambian. Esa diferencia resulta especialmente evidente cuando conviven esquemas como MARC, Dublin Core u otros modelos de descripción.

Los estándares y protocolos facilitan muchísimo este trabajo. En el catálogo digital de una biblioteca, por ejemplo, formatos, APIs y mecanismos de interoperabilidad permiten que la información pueda reutilizarse y circular entre distintos sistemas. OAI-PMH facilita la recolección de metadatos entre repositorios, pero ningún protocolo decide por sí solo cómo deben corresponderse todos los campos, qué hacer con la información que existe en un esquema y no en otro o cuál de los sistemas debe prevalecer cuando aparecen diferencias.

Por eso algunas bibliotecas disponen de integraciones técnicamente correctas que continúan necesitando bastante intervención humana alrededor. La información circula, aunque después alguien tenga que revisar lo que ha llegado.

Este es uno de los puntos en los que merece la pena mirar más allá del SIGB. Si una parte significativa del trabajo está dedicada a reconciliar datos entre repositorios, corregir importaciones o mantener equivalencias manualmente, probablemente haya que revisar el conjunto del flujo y no solamente uno de los programas implicados.

No todo tiene que vivir dentro del SIGB

Las distintas aplicaciones suelen estar ahí porque resuelven necesidades diferentes. Un repositorio institucional no trabaja exactamente con los mismos requisitos que el módulo de circulación y una colección patrimonial digitalizada puede necesitar una descripción, una estructura y unas formas de acceso propias. A ello se suman los sistemas corporativos de la institución, con funciones que quedan fuera del ámbito bibliotecario.

Pretender que una sola herramienta absorba toda esa actividad puede acabar creando tantos problemas como los que se quería evitar.

Lo importante es tener claro qué se gestiona en cada sitio y evitar que el reparto termine generando varias versiones de la misma información. Para ello conviene saber dónde nace cada dato, qué aplicación lo mantiene, quién puede modificarlo y cómo llega a los demás sistemas que lo necesitan.

Las APIs, los protocolos o los estándares bibliográficos ayudan a mover la información entre aplicaciones. Después quedan decisiones que son menos tecnológicas, pero igual de importantes. Hay que decidir quién mantiene cada dato, qué sucede cuando se modifica y qué sistema se toma como referencia cuando aparecen diferencias.

A veces sí hay que plantearse si la plataforma sigue siendo adecuada

Hay casos en los que el problema no está solo en las conexiones construidas alrededor del sistema. La propia plataforma puede empezar a limitar los procesos que la biblioteca necesita desarrollar.

La evolución hacia las Library Services Platforms (LSP) estuvo ligada, entre otras cosas, a la necesidad de gestionar de forma más homogénea colecciones impresas, electrónicas y digitales y de trabajar con arquitecturas más orientadas a servicios.

Eso tampoco convierte una migración en la respuesta inmediata.

Cambiar una plataforma bibliotecaria significa mover datos, revisar integraciones y, en muchos casos, modificar formas de trabajo que llevan años consolidadas. Existen dificultades relacionadas con la migración de grandes volúmenes de datos, la formación, los recursos humanos y el presupuesto.

Antes de plantear una migración conviene localizar dónde se está generando realmente la fricción. Puede estar en una integración que nunca se llegó a desarrollar, en unos metadatos que cada sistema maneja de forma distinta o en procesos manuales que fueron creciendo poco a poco alrededor de la plataforma. Si no se aclara eso antes, cambiar el SIGB puede trasladar parte de los mismos problemas al sistema nuevo.

También habrá bibliotecas en las que el análisis confirme que la arquitectura actual ya no permite seguir creciendo con razonable facilidad. Pero ese diagnóstico debería preceder a la elección de una nueva herramienta.

Seguir el recorrido de un registro suele ser bastante revelador

Una forma sencilla de empezar consiste en elegir algunos procesos habituales y seguir la información durante todo su recorrido.

Pensemos en una obra que se digitaliza. ¿Dónde se crea por primera vez su descripción? ¿Qué parte procede del SIGB? ¿Qué metadatos se generan durante la digitalización? ¿Hay que cargarlos después en un repositorio? ¿Se vuelve a escribir algún dato que ya existía? ¿Qué ocurre si el registro original cambia?

El mismo ejercicio puede hacerse con una publicación incorporada a un repositorio institucional, una autoridad modificada o cualquier recurso que tenga presencia en varias plataformas.

Al reconstruir el recorrido suelen aparecer tareas que hasta entonces estaban bastante normalizadas en el día a día. Puede haber una carga manual entre dos aplicaciones, un fichero que se exporta periódicamente para actualizar otra plataforma o pequeñas diferencias entre registros que el personal corrige cada vez que se produce un intercambio. Son precisamente esos pasos los que permiten ver cuánto trabajo exige mantener conectado el conjunto.

Con esa información resulta más fácil decidir qué merece la pena tocar. A veces habrá que mejorar una integración y en otras revisar primero cómo se están describiendo los recursos. Si distintas fuentes están generando registros para un mismo documento, puede ser necesario establecer mecanismos para identificar coincidencias y evitar que terminen incorporándose varias veces. También puede haber que revisar el proceso de digitalización o decidir qué sistema debe conservar la información de referencia.

Solo en algunos casos la conclusión será sustituir el SIGB.

La integración también ocurre fuera del SIGB

Durante mucho tiempo, hablar de un sistema «integrado» significaba reunir en una misma aplicación muchas de las funciones principales de la biblioteca. Hoy esa integración también se juega fuera de la propia aplicación.

Con los años, una biblioteca puede acabar dedicando bastante trabajo a sostener las relaciones entre el SIGB, los repositorios y las demás herramientas que ha ido incorporando. Exportar datos, corregir diferencias o repetir información puede terminar formando parte de la rutina hasta el punto de dejar de percibirse como un problema.

Revisar esos recorridos ayuda a saber si el sistema central sigue respondiendo bien, dónde se están produciendo las fricciones y qué procesos merece la pena replantear. Es también una parte del trabajo que conviene tener en cuenta al abordar la gestión bibliotecaria de forma más amplia.

Preguntas frecuentes sobre Sistema Integrado de Gestión de Bibliotecas