A Practical Look at the First Week
Cuando un cliente industrial nos entrega acceso a sus servidores por primera vez, la tentación es prometer resultados inmediatos. La realidad es más modesta: la primera semana se parece más a un trabajo de campo que a una demostración de producto. Hay que entender qué registros existen, dónde están guardados y qué formato tienen antes de que el motor de indexación pueda hacer algo útil.
En una planta de manufactura en Montevideo, el punto de partida fue un conjunto de carpetas compartidas con más de 40.000 archivos técnicos: manuales de equipos, órdenes de mantenimiento, informes de inspección y planos escaneados. Ninguno seguía una convención de nombres consistente. Algunos archivos tenían fechas en el título, otros solo un código interno, y varios estaban duplicados con versiones ligeramente distintas.
La primera decisión práctica fue no intentar limpiar todo a mano. En lugar de eso, configuramos el indexador para que reconociera patrones básicos: tipo de documento, número de equipo y rango de fechas. El objetivo no era perfecto, era suficiente para que un técnico pudiera encontrar un registro sin preguntar a un colega. Esa distinción importa porque cambia el criterio de éxito: no se trata de tener una base de datos impecable, sino de reducir el tiempo de búsqueda en situaciones reales.
El segundo día apareció el primer obstáculo concreto: los archivos PDF escaneados no tenían capa de texto. El motor de indexación no podía leer el contenido hasta que activamos el reconocimiento óptico de caracteres. Eso añadió horas de procesamiento, pero también reveló cuántos documentos críticos estaban en ese formato. Sin ese paso, la búsqueda habría devuelto resultados vacíos justo donde más se necesitaba información.
También tuvimos que negociar con el equipo interno qué campos eran prioritarios. El jefe de mantenimiento quería poder filtrar por fecha de última intervención; el supervisor de calidad necesitaba localizar informes por lote de producción. Ambas necesidades eran legítimas, pero requerían etiquetar los registros de manera distinta. La solución fue crear dos vistas sobre el mismo índice, en lugar de forzar una sola clasificación que no sirviera bien a ninguno de los dos.
Al final de la semana, el resultado no fue espectacular en términos de volumen procesado, pero sí fue claro en términos de uso: los técnicos empezaron a consultar el índice por su cuenta, sin que nadie les mostrara cómo hacerlo. Ese es el indicador que más nos interesa en una primera etapa. Si la herramienta se usa sin instrucciones, significa que el modelo mental detrás de la indexación coincide con la forma en que el equipo ya piensa sobre sus propios datos.
La lección principal de esos primeros días es que la indexación masiva no resuelve problemas de organización por sí sola. Lo que hace es exponerlos con claridad: muestra qué registros existen, cuáles están duplicados y qué información falta. Esa visibilidad, aunque incómoda al principio, es el punto de partida para cualquier mejora real en la gestión de datos técnicos. Si quieres conocer cómo seguimos el proceso después de esa primera revisión, puedes leer la nota sobre los cambios tras la revisión inicial.