La deduplicación está de moda. Más de lo que imaginas. De hecho, seguro que lo has «hecho» alguna vez: «deduplicar» registros de alguna de tus bases de datos. Y seguro que aún te quedan mucho por hacer. Como a mi cuñado (del que hablaré al final).
Pero empezaré por el principio. Si buscamos en Wikipedia encontramos la definición «técnica» de la deduplicación. Es una técnica que se utiliza sobre todo al hacer copias de seguridad de grandes bases de datos para ahorrar espacio. Básicamente es detectar bloques de información repetidos y guardar solo una vez este bloque, más una referencia cada vez que aparece de nuevo. A algunos nos recuerda el «viejo» compresor de ficheros de MS DOS, el PKZIP, que se popularizó tanto que Windows lo incorpora desde hace bastante años.
En bases de datos es especialmente eficiente. Si en mi lista de clientes tengo miles de «Martinez», solo guardo la palabra «completa» una vez y luego un código, que ocupa mucho menos espacio. En la gestión documental es aún más intesante porque se puede ahorrar mucho más espacio, sobre todo en grandes bases de datos. Imagina el ahorro de guardar una copia del contrato (de varias páginas) que han firmado miles de clientes. Salvo para la primera vez, para el resto solo hay que guardar la parte final con las firmas, la que es diferente en cada caso.
Pero no quería hablar de esta visión tan técnica de la deduplicación sino de su uso a un nivel mucho más cercano. Conozco una empresa que dedica muchísimo tiempo a «deduplicar» las bases de datos de sus clientes que no son otros que los bancos que se están creando últimamente en las fusiones de Cajas y Bancos, algo muy corriente últimamente. ¿Te imaginas el fichero de clientes que se forma al unir el de Caja Granada y Banco de Murcia (por ejemplo)? Millones de fichas de clientes que proceden de dos o más bases de datos gestionadas de forma diferente durante años.
El problema es importante: a nadie le gusta tener clientes repetidos. Y a ningún cliente le gusta recibir cartas duplicadas, por señalar solo uno de los problemas que se generan. Para complicar aún más las cosas, los datos de los clientes no siempre están «normalizados» de la misma forma. Piensa en la dirección: Paseo de la Castellana, 47, bloque 1, escalera derecha, piso 1-A. ¿De cuantas formas distintas se puede escribir esta dirección? Casi tantas como diseñadores de la base de datos que la contenga.
Y ahora llego al último afectado por la duplicidad de datos: mi cuñado. Acaba de cambiar de móvil, de HTC a iPhone. Además tiene un portátil con Outlook y en su oficina un ordenador de sobremesa, también con Outlook. Además aún le quedan muchos contactos apuntados ¡en una agenda impresa en papel que conserva en WordPerfect! Eso hace… 5 bases de datos de amigos, clientes, proveedores… en 4 formatos distintos. ¡No sabe por donde empezar! (a deduplicar, claro).
Convertir datos de diferentes fuentes en un único fichero común es un problema a veces inevitable. Lo que no tiene justificación posible es diseñar mal una base de datos desde el principio. Hay que evitar los futuros problemas de duplicidades desde antes de empezar a introducir datos. Y esta «regla de oro» se aplica también, por supuesto, a bases de datos documentales.
Así pues, cuando ordenes tus carpetas en Windows (o Mac), organices tus corres electrónicos (espero que en subcarpetas también) y por supuesto cuando instales y configures tu programa de gestión documental en el que vas a archivar decenas de miles de documentos de la empresa, recuerda la regla número 1: Un documento debe estar en un único sitio, tiene que haber una única versión «maestra». Todo lo demas deben ser referencias o copias.
Siempre hay que saber en dónde buscar «la versión original».
Gestión Documental Para Gente (Casi) Normal 
Deja una respuesta