Arquitectura multiusuario en Excel: cómo implementar un modelo cliente-servidor en Excel para tu laboratorio

Excel es una herramienta excelente para calcular y analizar, pero no nació para manejar escrituras concurrentes de muchos usuarios ni para ofrecer, “de fábrica”, controles típicos de una base de datos (bloqueo por registro, resolución de conflictos, auditoría automática). Aun así, en entornos regulados se sigue usando porque es general, flexible y rápido de desplegar, especialmente cuando la alternativa formal (LIMS/ERP/BD) tarda meses e implica costos muy elevados su implementación.

Sin embargo, Excel tiene muchas limitaciones y más cuando se habla de trabajar en conjunto con otros usuarios: Excel opera como archivo, no como motor transaccional. Por eso, la opción “multiusuario” suele resultar en archivos bloqueados, sobrescrituras, conflictos y pérdida de información.

En un Excel compartido en un SharePoint se puede trabajar sin ningún problema aparente con múltiples usuarios a la vez, sin embargo, esta solución no ofrece ninguna seguridad ni cumple con la regulación ya que no cuenta con gestión de usuarios, perfiles o Audit Trail. Para abordar estos puntos se debe automatizar el archivo con Macros. Sin embargo, en Excel para la web no se pueden crear, ejecutar ni editar macros de VBA; solo se puede abrir y editar el libro, y las macros quedan para el escritorio. En otras palabras, el recurso de macros solo funciona alojado en el equipo de cada usuario.

En resumen: el “Excel compartido” sirve para coeditar documentos, pero no es un sustituto limpio de un sistema de captura multiusuario con control y auditoría. ¿Cómo podemos implementar un sistema que cumpla con la normativa, que sea seguro en ambientes regulados y a su vez permita la interacción de múltiples usuarios? Para resolver esta pregunta, creamos un sistema cliente-servidor que simula una base de datos e interactúa con múltiples interfaces, creando un sistema de control de concurrencia, como se muestra en la imagen 1.

La idea es simple: tener un archivo Excel central (sin formato habilitado para macros) como una sola fuente de verdad y múltiples puntos de entrada controlados que contengan todo el recurso disponible por VBA.

• Archivo central: almacena los datos definitivos, idealmente en tablas estructuradas y con reglas de conservación, copias de seguridad y revisión. El enfoque encaja con expectativas de conservación, legibilidad y accesibilidad de datos durante su periodo de retención.
• Archivos cliente (uno por usuario): funcionan como “ventanilla”: capturan, validan y envían cambios al central. El usuario trabaja “en su copia”, pero el dato de referencia vive en el central.

Este modelo imita dos beneficios de una base de datos: control de escritura y centralización. Y, sobre todo, reduce el riesgo humano más común: modificar los datos por errores en la codificación o por libre acceso.

Ahora bien, resolviendo la arquitectura necesaria para abordar la limitación nativa de Excel, nos queda resolver lo siguiente: ¿Cómo evitar que dos personas escriban “al mismo tiempo” sobre el dato maestro evitando conflictos de sincronización?

Una base de datos lo resuelve con bloqueo por registro y resolución de conflictos. De hecho, Microsoft recomienda usar Access (y no Excel) cuando se anticipa que muchas personas trabajarán y se necesitan opciones sólidas para controlar actualizaciones, como bloqueo de registros y resolución de conflictos de sincronización. En Excel, esas funciones no vienen integradas como motor; por eso se “simulan”.

Para esto, se genera un registro de usuarios conectados (quién está usando el sistema y cuándo entró), esto nos permite detectar picos de uso, decidir si se permite escribir y limpiar “sesiones fantasmas” (por cierres inesperados o tiempo de inactividad). Así, cuando varios usuarios compiten por un recurso (la escritura), una buena técnica para reducir “choques” es introducir esperas aleatorias entre reintentos, en lugar de reintentar todos a la vez. En otras palabras, si el archivo central está ocupado, el usuario espera un intervalo breve y variable antes de volver a intentar.

Para hacer esto posible se introdujo en el sistema el archivo “.Lock”, el cual bloquea el archivo central por los segundos necesarios hasta que el usuario quien fue aleatoriamente el primero en tomar el control agrega, edita o elimina la información que le corresponde. Una vez esto sucede, el sistema elimina el archivo “.lock” dando así paso para el segundo usuario que se encuentra en espera. Cabe resaltar que todo esto sucede dentro del código, lo único que ven los usuarios que esperan a que sus cambios se realicen es un mensaje de espera y un contador de intentos. En la imagen 2, se muestra un esquema que resume el sistema de esperas aleatorias y bloqueo temporal.

En definitiva, este enfoque demuestra que, con creatividad y un entendimiento adecuado de las herramientas, es posible llevar Excel a escenarios que originalmente no fueron contemplados, incluso acercándolo a comportamientos propios de sistemas multiusuario. Sin embargo, es importante no perder de vista su naturaleza: Excel no está diseñado de forma nativa para gestionar concurrencia ni altas cargas de usuarios. Por ello, aunque estas soluciones pueden ser altamente efectivas en contextos controlados, cuando se requiere escalar a un número significativo de usuarios o garantizar mayor robustez operativa, resulta más apropiado considerar tecnologías especializadas como bases de datos o sistemas dedicados.