Cómo una empresa global de generación de demanda B2B redujo de 2–3 horas a 10 segundos el tiempo de consulta a su base de datos con un asistente RPA
Resumen del proyecto
| Aspecto | Detalles |
|---|---|
| Cliente | Empresa global de generación de demanda B2B que procesa grandes volúmenes de datos de empresas y leads |
| NDA | Se han anonimizado los nombres de la empresa, el proyecto, la infraestructura, los sistemas y las bases de datos internas |
| Usuarios | 10–15 usuarios internos |
| Servicio principal | Automatización robótica de procesos (RPA) |
| Servicio complementario | Consultoría de optimización y automatización del flujo de trabajo |
| Proceso | Consulta de la base de datos, extracción masiva de datos, selección de campos, normalización y exportación |
| Primera versión | En un sprint de dos semanas |
| Calendario del proyecto | Desarrollo inicial en enero, refactorización en marzo y optimización del rendimiento en mayo |
| Tecnología | UiPath Assistant, UiPath Orchestrator, base de datos, CSV, Excel |
| Tablas de datos | Tablas de datos de empresas procedentes de LinkedIn, ZoomInfo y Yahoo Finance |
| Resultado clave | Unos 5.000 dominios procesados en 10 segundos en lugar de 2–3 horas |
| Mejora de rendimiento | Aproximadamente 800 veces más rápido |
Respuesta corta
La empresa dependía de especialistas técnicos para las consultas rutinarias a la base de datos. Cada solicitud tenía que revisarse, planificarse en un sprint, traducirse en una consulta a la base de datos, exportarse, normalizarse, formatearse y devolverse al solicitante.
Desarrollamos un RPA DB Assistant que ofreció a los usuarios autorizados un acceso predecible y bajo demanda a las operaciones de extracción de datos más habituales. La versión inicial se entregó en un sprint de dos semanas. Tras la refactorización de marzo y la optimización del rendimiento de mayo, el bot procesaba una solicitud de 5.000 dominios en unos 10 segundos en lugar de 2–3 horas.
El resultado fue un proceso aproximadamente 800 veces más rápido, hasta 2–3 horas de trabajo humano ahorradas por cada solicitud rutinaria y una dependencia mucho menor del equipo de desarrollo.
El cliente
El cliente es una empresa global de generación de demanda B2B que procesa grandes volúmenes de datos de empresas y leads.
Varios equipos internos necesitan con regularidad información estructurada de las tablas de datos de empresas. Según la solicitud, los usuarios pueden necesitar recuperar registros de empresas por dominio o prooflink, seleccionar atributos concretos, contar los registros coincidentes en la base de datos, generar una muestra aleatoria o exportar un subconjunto de datos para su uso operativo posterior.
Los datos se almacenan en varias tablas de la base de datos con información procedente de fuentes como LinkedIn, ZoomInfo y Yahoo Finance.
El problema no era la falta de datos, sino que el acceso operativo a esos datos seguía requiriendo la intervención directa de especialistas técnicos.
El reto
Antes de la automatización, una solicitud rutinaria seguía este proceso:
- Un usuario de negocio enviaba una solicitud de datos.
- La solicitud se revisaba y se añadía a la planificación del sprint.
- Un desarrollador o especialista técnico aclaraba los filtros y campos necesarios.
- El especialista preparaba manualmente la consulta a la base de datos.
- Los datos se extraían de una o varias tablas.
- Los resultados se exportaban en archivos separados.
- Los archivos se formateaban y normalizaban manualmente.
- El resultado final se enviaba al solicitante.
Una solicitud típica requería una media de 2–3 horas de trabajo de un especialista.
La ejecución de la consulta era solo una parte del esfuerzo. También se dedicaba tiempo a interpretar la solicitud, preparar los filtros, seleccionar los campos, estructurar el resultado, normalizar los datos y entregarlos.
Esto provocaba varios problemas.
Durante la planificación de los sprints, las solicitudes operativas competían con las tareas de desarrollo de producto y de automatización, y los especialistas técnicos repetían una y otra vez operaciones de extracción similares en lugar de centrarse en el desarrollo.
Además, los usuarios de negocio no podían obtener resultados de inmediato, aunque la solicitud siguiera un patrón ya conocido.
El proceso era especialmente ineficiente con archivos de entrada grandes. Una solicitud con miles de dominios podía seguir requiriendo horas de preparación y de procesamiento manual del resultado.
Análisis inicial y definición del alcance
Abordamos esto como un problema del flujo de trabajo operativo, no de la base de datos.
El objetivo era claro: sacar de la cola de desarrollo el trabajo repetible de extracción de datos sin dar a los usuarios acceso ilimitado a la base de datos.
Durante el análisis inicial identificamos varios tipos de solicitudes recurrentes:
- Extracción de registros con filtros predefinidos.
- Procesamiento de un archivo de entrada con dominios o prooflinks.
- Devolución solo de los campos seleccionados.
- Recuento de los registros coincidentes en la base de datos.
- Generación de una muestra aleatoria.
- Exportación de los resultados a CSV o Excel.
- Creación de una carpeta de resultados estructurada con un estado de ejecución claro.
La primera versión se centró en estos patrones repetitivos. Las solicitudes analíticas personalizadas y los cambios en la base de datos quedaron fuera del alcance de la automatización y siguieron requiriendo revisión técnica.
Así, la solución se mantuvo controlada y, al mismo tiempo, cubrió las operaciones que generaban la mayor parte del trabajo repetitivo.
La solución
Desarrollamos un RPA DB Assistant en UiPath Assistant que se activa mediante atajos de teclado.
El bot funciona como una herramienta de trabajo gestionada para la extracción de datos. Los usuarios pueden lanzar operaciones predefinidas sin escribir consultas a la base de datos ni trabajar directamente con su estructura.
El modelo operativo implementado incluye:
- F2 – Consulta genérica: extrae datos de las tablas de LinkedIn, ZoomInfo o Yahoo Finance y exporta el resultado a CSV.
- F3 – Extracción por archivo de entrada: recibe dominios o prooflinks desde un archivo de entrada y devuelve los registros coincidentes en CSV o Excel.
- Alt+F2 – Solicitud de información: realiza recuentos de registros en la base de datos y genera muestras aleatorias.
El bot también crea las carpetas de salida necesarias, abre la carpeta de resultados e informa del estado de la ejecución. Estas funciones están documentadas como el modelo operativo principal del RPA DB Assistant.
Estructura de la solución
| Bloque de la solución | Qué implementamos | Resultado operativo |
|---|---|---|
| Interacción con el usuario | Flujo en UiPath Assistant que se activa con atajos de teclado | Los usuarios ejecutan operaciones gestionadas sin conocimientos de bases de datos |
| Extracción genérica de la base de datos | Consultas definidas sobre tres tablas de datos de empresas | Se eliminó la preparación manual y repetida de consultas |
| Procesamiento masivo de archivos | Extracción por dominios y prooflinks a partir de archivos CSV o Excel | Las solicitudes grandes se ejecutan como una única operación automatizada |
| Procesamiento de campos seleccionados | Lógica que devuelve solo los campos necesarios | Mayor rapidez al evitar procesamiento innecesario |
| Recuento y muestreo | Funciones automáticas de recuento y de muestra aleatoria | Las solicitudes rutinarias de validación ya no requieren intervención técnica |
| Estandarización de la salida | Generación automática de archivos CSV y Excel | Se eliminó la mayor parte del formateo y la normalización manuales |
| Gestión de carpetas | Creación y apertura automáticas de las carpetas de resultados | Entrega de resultados siempre homogénea |
| Informe de ejecución | Estado de ejecución en el entorno de UiPath | Mayor visibilidad de finalizaciones y errores |
Proceso de implementación
Implementamos la solución en tres fases bien definidas.
Enero: desarrollo inicial
La primera versión funcional se entregó en un sprint de dos semanas.
El alcance inicial cubría los principales escenarios de extracción y ofrecía a los usuarios su primera interfaz de autoservicio. La prioridad era sacar cuanto antes las solicitudes rutinarias de la ejecución manual basada en sprints.
Marzo: refactorización
Tras el primer periodo de uso, refactorizamos la solución.
Los objetivos principales eran:
- Simplificar la estructura interna de los flujos.
- Facilitar el mantenimiento.
- Unificar la interacción con las distintas tablas de la base de datos.
- Mejorar la lógica de procesamiento de filtros y campos.
- Preparar el bot para volúmenes de entrada mayores.
- Reducir el esfuerzo necesario para añadir nuevos campos o escenarios de extracción.
No planteamos la refactorización como una reconstrucción desde cero. Se basó en el comportamiento de la versión inicial y en las solicitudes operativas reales recibidas tras el lanzamiento.
Mayo: optimización del rendimiento
La última fase se centró en el procesamiento de grandes volúmenes.
El principal cuello de botella era la lógica de procesamiento de campos seleccionados. Las solicitudes grandes podían contener miles de registros, mientras que los usuarios normalmente solo necesitaban un subconjunto concreto de campos.
Introdujimos una nueva clase para procesar los campos seleccionados y ajustamos el algoritmo con grandes volúmenes de datos.
Tras la optimización:
- El caso completo de 5.000 dominios se ejecutaba en 10 segundos.
- El componente más complejo de procesamiento de campos seleccionados tardaba cuatro segundos.
- El algoritmo se mantenía estable en solicitudes de gran volumen.
Este enfoque por fases permitió aportar valor de negocio rápidamente y, después, mejorar la arquitectura y el rendimiento a partir del uso real y no de suposiciones.
Stack tecnológico
| Capa | Tecnología | Función |
|---|---|---|
| Interfaz de usuario | UiPath Assistant | Lanzamiento de flujos con atajos de teclado |
| Automatización | UiPath | Extracción, procesamiento de archivos, normalización y exportación |
| Orquestación | UiPath Orchestrator | Despliegue, gestión de paquetes y estado de ejecución |
| Base de datos | Base de datos de la empresa | Almacenamiento y extracción de información de empresas |
| Tabla de datos | Tabla de LinkedIn | Información de empresas y perfiles |
| Tabla de datos | Tabla de ZoomInfo | Información de empresas y datos firmográficos |
| Tabla de datos | Tabla de Yahoo Finance | Información financiera y de empresas cotizadas |
| Entrada | CSV y Excel | Listas de dominios y prooflinks |
| Salida | CSV y Excel | Entrega estructurada de resultados |
Resultados
| Métrica | Antes | Después | Resultado |
|---|---|---|---|
| Tiempo de procesamiento de la solicitud de prueba de 5.000 dominios | 2–3 horas | 10 segundos | Aproximadamente 800 veces más rápido |
| Esfuerzo humano por solicitud rutinaria | 2–3 horas de un especialista | Solo lanzamiento y revisión del resultado | Hasta 2–3 horas ahorradas por solicitud |
| Capacidad de procesamiento | Preparación y exportación manuales | 5.000 dominios en 10 segundos | Unos 500 dominios por segundo en el escenario de prueba |
| Procesamiento complejo de campos seleccionados | Dependía de la consulta manual y de la estructura de exportación | 4 segundos | Procesamiento estable de grandes volúmenes |
| Recepción de solicitudes | Requería planificación en un sprint | Disponible bajo demanda | Solicitudes rutinarias fuera de la cola de desarrollo |
| Cobertura de usuarios | Dependencia de especialistas técnicos | 10–15 usuarios | Acceso de autoservicio controlado |
| Preparación de la salida | Exportaciones separadas y normalización manual | Salida estandarizada en CSV o Excel | Preparación manual prácticamente eliminada |
| Cobertura de fuentes de datos | Trabajo manual separado para cada fuente | Tres tablas de la base de datos | Un único flujo para el usuario |
La comparación entre 2–3 horas y 10 segundos arroja un rango calculado de entre 720 y 1.080 veces. Utilizamos la cifra redondeada de aproximadamente 800 veces más rápido.
No se calculó el ahorro de trabajo mensual ni anual porque no se disponía del número de solicitudes al mes. Por eso, el ahorro confirmado se presenta por solicitud, sin extrapolaciones.
¿Quiere ver qué solicitudes de su equipo podrían funcionar así? Reserve una revisión gratuita de sus procesos.
Lo que resultó difícil
Procesamiento de campos a gran escala
El reto técnico más importante fue procesar grandes conjuntos de resultados devolviendo solo los campos solicitados por el usuario.
La primera implementación funcionaba con volúmenes estándar, pero necesitaba optimizarse para archivos más grandes y combinaciones de campos más complejas.
Lo resolvimos con la refactorización de marzo y la nueva clase de procesamiento de campos seleccionados introducida en la fase de optimización de mayo. La parte más compleja del algoritmo se redujo a cuatro segundos.
Estructuras de base de datos diferentes
Las tablas de LinkedIn, ZoomInfo y Yahoo Finance tienen estructuras y conjuntos de campos diferentes.
Implementar cada fuente por separado habría supuesto tres soluciones distintas y un mayor esfuerzo de mantenimiento. En su lugar, separamos la lógica de extracción específica de cada fuente de los componentes compartidos de procesamiento, exportación, gestión de carpetas e informe de estado.
Acceso controlado
La automatización debía reducir la dependencia de los desarrolladores sin abrir un acceso ilimitado a la base de datos.
El modelo basado en atajos de teclado lo resolvió dando a los usuarios acceso solo a las operaciones de extracción admitidas. La lógica de las consultas, la gestión de las conexiones y el procesamiento específico de la base de datos permanecieron dentro de la automatización.
Impacto operativo
El resultado principal no fue solo una ejecución más rápida de las consultas.
El proyecto cambió el modelo de responsabilidad del proceso.
Antes de la implementación, la extracción estandarizada de datos se trataba como trabajo de desarrollo. Después, pasó a formar parte de la operativa diaria.
Esto aportó tres beneficios directos:
- Los desarrolladores dejaron de dedicar varias horas a solicitudes de extracción y exportación.
- Los usuarios recibían los resultados sin esperar a la planificación del sprint.
- La empresa obtuvo una estructura reutilizable para añadir nuevas tablas, campos y escenarios de extracción habituales.
La solución también hizo la entrega más predecible. Las solicitudes rutinarias dejaron de depender de la carga del sprint en curso o de la disponibilidad de un especialista técnico concreto.
Qué significa esto para empresas similares
Este enfoque es relevante para empresas que ya tienen datos centralizados, pero siguen dependiendo de los desarrolladores para acceder a ellos en tareas rutinarias.
Algunas señales típicas:
- Las exportaciones estándar se tramitan como tickets de desarrollo.
- Los ingenieros preparan una y otra vez consultas similares a la base de datos.
- Los usuarios envían listas de dominios, empresas, ID o prooflinks para enriquecerlas.
- Los resultados requieren preparación manual en CSV o Excel.
- La consulta se ejecuta rápido, pero la solicitud completa tarda horas.
- El trabajo operativo interrumpe con regularidad el desarrollo planificado.
En lugar de automatizar todas las solicitudes posibles a la base de datos, lo correcto es empezar por identificar los patrones de solicitud recurrentes, definir los formatos de entrada y salida y automatizar solo las operaciones que pueden ejecutarse de forma consistente.
En este proyecto, la primera versión utilizable se entregó en dos semanas. La refactorización y la optimización del rendimiento se completaron después, a partir del uso real en producción y de pruebas con grandes volúmenes.
Cómo ayuda 2BBooster en proyectos similares
En proyectos similares de acceso a datos y automatización interna, nuestro enfoque incluye:
- Mapear el proceso actual de solicitudes y aprobaciones.
- Medir el esfuerzo manual real por solicitud.
- Separar las operaciones repetibles del trabajo analítico personalizado.
- Definir escenarios de acceso gestionado.
- Construir la primera versión operativa en torno a los casos de uso de mayor volumen.
- Probar la solución con archivos de tamaño real de producción.
- Refactorizar a partir del uso real.
- Añadir monitorización y salidas estructuradas, y asignar responsables del soporte.
Servicios relacionados:
- Automatización robótica de procesos (RPA)
- Consultoría de optimización y automatización del flujo de trabajo
Preguntas frecuentes
¿Cuánto duró el proyecto?
La primera versión funcional se entregó en un sprint de dos semanas.
¿Necesitaban los usuarios acceso directo a la base de datos?
No. Los usuarios trabajaban con funciones predefinidas de UiPath Assistant. El acceso a la base de datos y la lógica de las consultas permanecían dentro de la automatización.
¿Qué operaciones se automatizaron?
El bot permitía la consulta genérica, el procesamiento por archivo de entrada con dominios o prooflinks, la extracción de campos seleccionados, el recuento de registros en la base de datos, el muestreo aleatorio y la exportación a CSV o Excel.
¿Cuántos usuarios trabajaban con el bot?
Entre 10 y 15 usuarios internos tenían acceso a las funciones de extracción admitidas.
¿Cómo funcionaba el bot con solicitudes grandes?
En el escenario de prueba confirmado, se procesaron unos 5.000 dominios en 10 segundos. El componente más complejo de procesamiento de campos seleccionados tardaba cuatro segundos.
¿La solución eliminó la necesidad de especialistas técnicos?
Eliminó la intervención técnica en las solicitudes de extracción estandarizadas. Los análisis personalizados, las nuevas estructuras de bases de datos y los tipos de solicitud no admitidos siguieron requiriendo revisión técnica.
Conclusión
El DB Assistant convirtió una solicitud técnica dependiente de los sprints en un proceso de autoservicio controlado.
La primera versión se entregó en dos semanas. Después, la refactorización y la optimización del rendimiento prepararon la solución para trabajar con grandes volúmenes en producción.
En el escenario confirmado de 5.000 dominios, el tiempo de procesamiento pasó de 2–3 horas a 10 segundos. Esto supone una mejora de aproximadamente 800 veces y hasta 2–3 horas de trabajo de un especialista ahorradas por cada solicitud rutinaria.
El resultado final fue un acceso más rápido a los datos, menor dependencia del desarrollo, resultados consistentes y una estructura mantenible, ampliable a medida que surgían nuevos escenarios operativos.
Las consultas estándar a la base de datos no tienen por qué pasar por desarrollo
Si las exportaciones rutinarias de la base de datos, las búsquedas de datos, las solicitudes de enriquecimiento o los informes de su equipo siguen pasando por la planificación de sprints, normalmente hay una clara oportunidad de automatización.
Podemos mapear el flujo actual de solicitudes, identificar qué operaciones son repetibles y definir cómo podría ser una capa de autoservicio consistente sobre sus bases de datos y herramientas actuales.
Reserve una revisión gratuita de sus procesos para identificar qué consultas a la base de datos puede sacar primero de su cola de desarrollo.
Lea también
Estrategia de optimización de la nube: cómo tomar el control del gasto en la nube
Gestionar los costes de la nube es hoy el principal reto cloud de la mayoría de las organizaciones. Cuatro prácticas ayudan a recuperar el control: monitorizar el uso, ajustar el tamaño de los recursos, aprovechar los descuentos por compromiso y…