Sistemas "a la medida":
Presentado durante el VII Coloquio de Automatización de Bibliotecas, Universidad de Colima, México. 22 de Noviembre de 1995.
Contenido:
- Abstracto
- Introducción
- Requerimientos y características de InfoLib
- Entorno Administrativo de desarrollo
- Recomendaciones
Abstracto
Es necesario evaluar cuidadosamente la conveniencia de desarrollar un sistema propio de información y administración de bibliotecas. Si es cierto que el sistema ideal se otiene partiendo de las necesidades específicas de la biblioteca - y no imponiendo un producto existente -, también es cierto que desarrollar e implementar un sistema es un proceso largo y complejo. Por lo tanto, antes de desarrollar un sistema propio, es necesario revisar las siguientes premisas: 1) no es posible adquirir un sistema que satisfaga la mayoría de las características deseadas, y 2) se dan las condiciones administrativas necesarias para desarrollar el sistema internamente. El objetivo de este artículo es ilustrar ambas premisas utilizando el caso real del sistema "InfoLib". Este sistema fue desarrollado en 1993 a partir de las necesidades de la biblioteca de la Universidad Francisco Marroquín en Guatemala.
Introducción
La Universidad Francisco Marroquín (UFM) está situada en la ciudad de Guatemala. Es considerada una de las más importantes y mejor organizadas en el país, y probablemente de toda Centroamérica. La biblioteca de la UFM sirve a los 5,000 estudiantes de la universidad y a numerosos usuarios de otras universidades y colegios del país. En 1992 la colección contenía unos 33,000 volúmenes y unos 600 títulos de revistas. Hacia principios de 1995 la colección había crecido a unos 44,000 volúmenes.
A finales de 1992 se contempló la posibilidad de implementar un sistema de automatización de bibliotecas que pudiera servir al personal de la biblioteca y a sus usuarios por los siguientes 5 años. Aunque a primera vista 5 años pudiera parecer cortoplacista, en realidad es el objetivo más complejo y difícil de cumplir ya que los cambios tecnológicos son impredecibles y pueden volver obsoleto cualquier sistema de un año para otro.
Aunque no es posible aplicar una metodología definida para garantizar la vigencia de un sistema, sí establecimos tres objetivos fundamentales que probaron ser útiles:
- La información almacenada debe existir por un período mucho mayor que la vida útil del sistema. Como no es posible saber las características de los subsiguientes sistemas y formatos, es importante que el sistema a implementar no imponga ningún formato en particular. El sistema también debe ayudar a mantener y mejorar la información que va a almacenar durante su vida útil.
- Debe seleccionarse la tecnología de implementación pensando en los siguientes 5 años, y no en los 5 años anteriores. Por ejemplo, si en 1995 alguien deseara implementar un sistema en DOS con una herramienta como Dbase o FoxPro, dentro de 5 años, en el 2000, no podrá conseguir nuevas versiones de Dbase o FoxPro para DOS, ni programadores que conozcan las herramientas. Al mismo tiempo, su sistema carecerá de la funcionalidad que será estándar en el 2000.
- El sistema debe estar desarrollado en herramientas abiertas que permitan su evolución. En una plataforma abierta es más factible la implementación de nuevos servicios conforme va surgiendo la tecnología para ofrecerlos. En el caso de InfoLib, por ejemplo, su plataforma abierta permite incorporar consultas a la base de datos vía World Wide Web (WWW).
Para analizar la decisión de desarrollar InfoLib desde la perpectiva correcta, es necesario recordar el estado de la tecnología a finales de 1992. La primera versión realmente estable de Windows, la 3.1, había aparecido hacía sólo 7 meses. La mayoría del personal de la biblioteca no tenía experiencia con interfases de vetanas y nunca había utilizado un mouse. En ese entonces se empezaba a hablar de sistemas cliente-servidor con interfases gráficos, y era difícil encontrar las herramientas y el personal adecuado para desarrollar en esta arquitectura. La mayor parte de los sistemas para bibliotecas se basaban en terminales tontas o redes Novell, y en interfases de caracteres.
A finales de 1992, ninguno de los sistemas disponibles en el mercado permitían satisfacer los requerimientos que Grete Pasch había establecido como necesarios para garantizar la funcionalidad y la vigencia del sistema. Sin embargo, la UFM ofrecía las condiciones administrativas óptimas para desarrollar e implementar un sistema internamente.
En la primera parte de este artículo presentamos un breve resumen de los requerimientos definidos en ese entonces y que ahora forman parte las características de InfoLib, y en la segunda parte discutimos las condiciones de carácter administrativo que hicieron posible el desarrollo y la implementación del sistema. Para concluír, resumimos varias recomendaciones que consideramos pueden ser útiles en experiencias similares.
1. Requerimientos y características de InfoLib
1.1 Amigable al usuario (user friendly)
La facilidad de uso del sistema juega un papel decisivo en la calidad de servicio que la biblioteca presta a sus usuarios. Si los interfases al usuario no son amigables, las consultas al catálogo resultan inadecuadas o requieren de asistencia por parte del personal. Cuando el sistema no ayuda al personal de la biblioteca a mantener ágil y efectivamente la información, entonces los usuarios obtienen información atrasada e incorrecta. Por esta razón es que ser 'amigable al usuario' encabeza nuestra lista de requerimientos.
A diferencia de los sistemas administrativos convencionales, un sistema de automatización de bibliotecas posee dos tipos bien diferenciados de usuarios:
- Usuarios de la biblioteca. Los interfases más complejos de desarrollar son aquellos orientados al público de la biblioteca. éstos no sólo deben ser fáciles de usar, sino también fáciles de aprender a usar. En nuestro caso, resultaba poco práctico tener que entrenar más de 5,000 estudiantes y catedráticos, y a los usuarios ocasionales ajenos a la universidad. Para evitar el entrenamiento, los interfases deben ser sumamente amigables e intutivos, por lo que es necesario recurrir a metodologías y principios de human factors para garantizar la efectiva utilización de multiventanas, mouse y pantallas sensibles al tacto (touchscreens).
- Personal de la biblioteca. Para este grupo, el objetivo principal del sistema es agilizar y mejorar la exactitud de su trabajo. Por ejemplo, el sistema de catalogación aprovecha el ambiente de multiventanas para asegurarse que el catalogador tiene acceso a toda la información que requiere (i.e. ingresar un nuevo autor en la tabla de autoridades, consultar CD-MARC, etc.) sin necesidad de interrumpir la catalogación del material a la mano.
Un requerimiento que consideramos importante, tanto para los usuarios de la biblioteca como para su personal, fue que el sistema "hablara español". Es decir, que alfabetizara correctamente utilizando tildes y eñes, y permitiera el ingreso y la búsqueda con la ortografía correcta.
1.2 Sistema Completo
El sistema contiene todos los módulos necesarios (catalogación, consulta, periódicas, estadísticas, circulación), y además, algunos adicionales, como el de inventario físico, que permite determinar materiales faltantes y provee listados para facilitar la reordenación de las estanterías, y el de kiosko de información por medio de touchscreen, que permite a los lectores revisar su estatus de préstamos, transmitir sus sugerencias, y enterarse de las nuevas adquisiciones, eventos, e información general de la biblioteca.
También es completo en cuanto al grado de automatización que ofrece a sus usuarios. Para conveniencia de los catalogadores, el sistema tiene detalles como el cálculo automático del número de Cutter, la extracción de palabras clave usadas en búsquedas, y el mantenimiento transparente de archivos de autoridades. También evita automáticamente el artículo inicial del título al alfabetizar, y esto en varios idiomas.
1.3. Integrado
Esto significa que todos los módulos trabajan en conjunto, compartiendo información en línea. Por ejemplo, al prestar un libro a través del módulo de circulación, inmediatamente el cambio se refleja en las consultas a través del OPAC (Online Public Access Catalog), en el estatus del préstamos del kiosco de información, y en las estadísticas. Al catalogar un nuevo material, automáticamente aparece en la lista de nuevas adquisiciones en el kiosco y, si así se desea, disponible para su circulación. Este nivel de integración descarga al personal de tediosas tareas de actualización, y reduce la ocurrencia de errores.
1.4 En red
La arquitectura cliente-servidor resulta ser la más adecuada para integrar todos los componentes del sistema a un costo razonable. De esta forma es posible interconectar las estaciones de trabajo en catalogación, OPAC y circulación con el servidor central y el kiosco de información. La arquitectura de red permite que en un futuro, sea posible prestar acceso remoto en la red del campus y vía internet utilizando World Wide Web (WWW).
2. Entorno administrativo de desarrollo
El sistema puede ser teóricamente perfecto - pero todos los sistemas computarizados forman parte de un entorno social, que es determinante en su éxito o fracaso. De acuerdo con nuestras experiencias, los siguientes factores, que no son necesariamente técnicos, fueron los más importantes en el desarrollo exitoso de INFOLIB.
2.1 Apoyo Institucional
Desde que empezamos la planificación del proyecto, logramos contar con el apoyo total del Consejo Directivo de la universidad. Este apoyo se manifestó en dos maneras: confianza y libertad de acción, y contacto constante.
Primero, una vez aprobado el proyecto, tuvimos total libertad de acción, incluyendo las decisiones presupuestarias, contratación de personal, selección de distribuidores de equipo, etc. Esto nos permitió actuar rápidamente, y también ajustar nuestros planes sin atajos burocráticos. Y en segundo lugar, mantuvimos contacto constante con el Consejo Directivo a través de uno de sus miembros, quien se auto-eligió para esta tarea con mucho entusiasmo y se mantuvo enterado de nuestros progresos y necesidades.
2.2 Equipo de Trabajo bien integrado y designación de un responsable
Formamos dos grupos de usuarios (catalogación y circulación) para discutir semanalmente dudas y sugerencias para el sistema final. Los usuarios trabajaron con los analistas y programadores en la definición del sistema y en las pruebas y refinamiento de los prototipos de cada módulo del sistema. Aunque siempre tratamos de buscar un consenso, las decisiones finales fueron tomadas por una sóla persona, que como directora del proyecto, se hizo responsable de todos los detalles de diseño, implementación y operación. En general, esta persona debería tener experiencias tanto en computación como en bibliotecología, y ser parte del personal de la biblioteca.
Una vez el sistema entró a funcionar, establecimos procedimientos de respaldo de datos (back-ups), instalación de módulos del sistema, mantenimiento del hardware (limpieza, reparación, instalación), emergencias (falla de luz, robos), y sobre todo, la rutina diaria: encargados de encender y apagar equipos cada día, y un responsable de mantener las impresoras funcionando (papel, cintas, etc.) Contratamos un grupo de estudiantes de la carrera de sistemas de computación, que se encarga del soporte técnico a todo el personal y del mantenimiento de equipo, bajo la supervisión directa de la directora de proyecto.
Como al trabajar directamente en pantalla la catalogación se facilitó y se hizo más rápida, se contrataron catalogadores por "destajo", a quienes se les paga por libro trabajado, y quienes se turnan el uso de nuestra terminal "CD-MARC", y las terminales de catalogación.
2.3 Relación positiva con analistas y programadores
Muchas bibliotecas no tendrán su grupo propio de analistas y programadores de sistemas, y como en el caso de la UFM, deberán contratar estos servicios externos. Aunque es posible contratar programadores temporalmente, es recomendable acercarse a una firma establecida de consultores que realice este desarrollo por uno - sobre todo porque si el proyecto dura varios años, una empresa podrá garantizar continuidad en los servicios, y además, tendrá la experiencia necesaria en el manejo de este personal y los conocimientos técnicos más actualizados.
Una relación contractual donde se paga contra resultados verificados es más segura para la institución. Elaboramos un documento donde describimos lo mejor posible la funcionalidad esperada, y solicitamos propuestas de varias empresas. Elegimos la más factible, y establecimos de común acuerdo un cronograma de actividades con fechas de entrega y pruebas. Es importante adquirir la intuición de lo que es posible y lo que no a la hora de redactar las especificaciones, y establecer una relación de confianza a este respecto con su equipo de desarrollo.
La persona que dirige el proyecto deberá manejar la interacción con los analistas y programadores. Para esto, un par de consejos. Pida a los analistas que trabajen en el mostrador de circulación y también, que aprendan el proceso de catalogación y trabajen haciéndolo por un tiempo. No acepte que simplemente le pregunten cómo es el proceso y luego, que traten de replicarlo en el sistema - sobre todo si no tienen experiencia previa en sistemas de bibliotecas. Y asegúrese de que entienden el sistema de clasificación que está en uso, y también que aprendan a encontrar materiales usando el fichero.
Sea firme en cuanto a no aceptar cambios en el personal de desarrollo de analistas ni de programadores a medio proyecto. Programar es un arte, y aunque las rutinas en cada programa estén bien documentadas, un programador nuevo tendrá que invertir tiempo entendiendo lo que hicieron sus predecesores y porqué.
Cuando le entreguen una versión nueva del sistema, haga una revisión muy cuidadosa y anote cada problema que encuentre. Luego reúnase con el encargado de esa parte y revísenlo juntos. Revisar el sistema exhaustivamente cada vez que hay cambios es la única forma de garantizar que todo funciona como se espera.
Finalmente, como estrategia de diseño seguimos un desarrollo por prototipos. La mayoría de metodologías convencionales que usan los analistas de sistemas tienen una desventaja: se necesita entrenamiento especial para entender la notación y técnicas utilizadas. Como resultado, el usuario final no entiende cómo va a ser el sistema. Si se desarrollan prototipos, estos pueden ser probados y mejorados sobre la marcha, e incluso llegar a convertirse en el producto final, como sucedió en nuestro caso. Recuerde que sus usuarios finales son los lectores que acuden a la biblioteca buscando información: el interfase del OPAC tiene que ser probado con estos usuarios antes de ser formalmente aceptado.
2.4 Enfatizar la Calidad de la Información
Recuerde que el éxito del sistema dependerá del provecho que los usuarios de la biblioteca obtengan, es decir, que encuentren la información que necesitan. Por eso, la información en el sistema debe ser lo más completa y correcta posible, y la única forma para lograr esto es revisando y corrigiendo lo mejor posible todos los datos que se encuentran en el sistema. En nuestro caso, migramos de un sistema anterior, no normalizado, a INFOLIB. Tuvimos que revisar una lista de más de 22,000 autores y eliminar o corregir cerca de 8,000 falsos duplicados y nombres con errores. Lo mismo sucedió con los nombres de las editoriales, ciudades y países, listados de idiomas, formatos de los materiales, etc.
Estas revisiones nos llevaron cientos de horas de trabajo, y nos dejaron una lección bien clara: sea cual sea el sistema utilizado, es importante que la información se ingrese bien, preferiblemente desde la primera vez. Todos los módulos de INFOLIB fueron diseñados en base a esta necesidad, y facilitan el control de calidad mediante chequeos en línea, y gracias al diseño relacional de los datos.
Los sistemas van y vienen - los datos deben prevalecer, y de allí la importancia de tenerlos lo más exactos posible.
Recomendaciones
Desarrollar un sistema es un proceso largo y complejo. Por eso, antes de desarrollar un sistema propio, es necesario asegurar que: 1) no es posible adquirir un sistema que satisfaga la mayoría de las características deseadas, y 2) se dan las condiciones administrativas necesarias para desarrollar el sistema internamente.
Si ningún sistema existente satisface sus necesidades y no se dan las condiciones para desarrollarlo internamente, piense en una solución híbrida: adquirir un sistema y adaptarlo con programación adicional. Para esto es importante que el sistema a adquirir sea abierto y adaptable.
Enmarque la vida útil de su sistema y la información que almacena en la perspectiva correcta. Al desarrollar InfoLib, nos apoyamos en los siguiente lineamientos: 1) La información almacenada debe existir por un período mucho mayor que la vida útil del sistema, 2) Al seleccionarse la tecnología de implementación hay que pensar en los siguientes 5 años, y no en los 5 años anteriores y 3) el sistema debe estar desarrollado en herramientas abiertas que permitan su evolución.
Recuerde que todos los sistemas computarizados forman parte de un entorno social, que es determinante en su éxito o fracaso. Para esto es importante obtener apoyo institucional, un director responsable del proyecto que sea capaz, y un equipo de trabajo integrado y motivado.
Más información? ... Comentarios? ... Sugerencias?