Cuando llega un aviso del proveedor con un número de lote en la mano, no quieres navegar seis menús. Quieres escribirlo y que aparezca. Eso es lo que hace un buscador global —y por qué es más difícil de construir de lo que parece.
10 de septiembre de 2026
Los menús sirven cuando no sabes bien qué buscas. Pero la mayor parte del tiempo, en la operación ya sabes exactamente qué necesitas: esa guía de despacho, ese cliente, ese lote. Obligar a la persona a recordar en qué producto y en qué submenú vive cada cosa es fricción pura, repetida cientos de veces al día.
Un buscador global le da la vuelta: Ctrl+K en cualquier pantalla, escribes, y saltas directo al resultado. Como el buscador de tu computador, pero para tu operación.
La caja de búsqueda es lo fácil. Lo difícil es que encuentre todo lo relevante y siga encontrándolo cuando el sistema crece. El error común es escribir a mano, en cada producto, una lista de "qué se puede buscar aquí". Con esa arquitectura, cada vez que agregas una entidad nueva tienes que acordarte de sumarla en varios lugares; y si te olvidas, no se rompe nada visible: simplemente esa cosa deja de encontrarse, en silencio. Es el mismo defecto que tener el mismo dato copiado en muchos lados.
En la suite el índice de búsqueda vive en un solo lugar y todos los productos escriben en él. Por eso, desde una misma caja, Ctrl+K encuentra:
Un solo dato, un solo índice: por eso buscar "L2026-0007" te lleva al lote aunque estés parado en Finanzas, y buscar el RUT de un cliente te lo muestra sin importar desde qué producto entraste.
Un buscador que cruza lotes, guías, clientes y personas requiere que todo eso viva en la misma base. Si tienes un sistema para bodega, otro para finanzas y una planilla para personas, no hay Ctrl+K que valga: cada búsqueda muere en la frontera del sistema. La búsqueda transversal no es una feature que se agrega; es una consecuencia de tener un solo dato.
← Volver al blog