Як глобальна B2B-компанія з генерації попиту скоротила час запитів до бази даних з 2–3 годин до 10 секунд за допомогою RPA-асистента
Коротко про проєкт
| Параметр | Деталі |
|---|---|
| Клієнт | Глобальна B2B-компанія з генерації попиту, що обробляє великі обсяги даних про компанії та ліди |
| NDA | Назви компанії, проєкту, інфраструктури, систем і внутрішніх баз даних анонімізовано |
| Користувачі | 10–15 внутрішніх користувачів |
| Основна послуга | Роботизована автоматизація процесів (RPA) |
| Додаткова послуга | Консалтинг з оптимізації та автоматизації робочих процесів |
| Процес | Вибірка даних із бази, масове вивантаження, вибір полів, нормалізація та експорт |
| Перша версія | За двотижневий спринт |
| Терміни проєкту | Початкова розробка в січні, рефакторинг у березні, оптимізація продуктивності в травні |
| Технології | UiPath Assistant, UiPath Orchestrator, база даних, CSV, Excel |
| Таблиці даних | Таблиці з даними про компанії з LinkedIn, ZoomInfo та Yahoo Finance |
| Ключовий результат | Близько 5 000 доменів обробляються за 10 секунд замість 2–3 годин |
| Приріст продуктивності | Приблизно у 800 разів швидше |
Коротка відповідь
Компанія залежала від технічних фахівців у виконанні типових запитів до бази даних. Кожен такий запит треба було розглянути, внести у спринт, сформувати під нього запит до бази, вивантажити дані, нормалізувати, відформатувати й повернути ініціатору.
Ми створили RPA DB Assistant, який дав авторизованим користувачам передбачуваний доступ на вимогу до найпоширеніших операцій вибірки даних. Першу версію реалізували за двотижневий спринт. Після рефакторингу в березні та оптимізації продуктивності в травні бот обробляв запит на 5 000 доменів приблизно за 10 секунд замість 2–3 годин.
У результаті процес став приблизно у 800 разів швидшим, на кожному типовому запиті вдалося заощаджувати до 2–3 годин роботи фахівців, а залежність від команди розробки суттєво зменшилася.
Клієнт
Клієнт — глобальна B2B-компанія з генерації попиту, яка обробляє великі обсяги даних про компанії та ліди.
Кілька внутрішніх команд регулярно потребують структурованої інформації з таблиць із даними про компанії. Залежно від запиту користувачам може знадобитися знайти записи про компанії за доменом або prooflink, вибрати конкретні атрибути, порахувати відповідні записи в базі даних, сформувати випадкову вибірку або вивантажити частину даних для подальшої операційної роботи.
Дані зберігаються в кількох таблицях бази даних, що містять інформацію з таких джерел, як LinkedIn, ZoomInfo та Yahoo Finance.
Проблема була не в нестачі даних. Операційний доступ до них і досі вимагав безпосередньої участі технічних фахівців.
Виклик
До автоматизації типовий запит проходив такий шлях:
- Бізнес-користувач надсилав запит на дані з бази.
- Запит розглядали й додавали до планування спринту.
- Розробник або технічний фахівець уточнював потрібні фільтри й поля.
- Фахівець вручну готував запит до бази даних.
- Дані вибирали з однієї або кількох таблиць.
- Результати вивантажували в окремі файли.
- Файли вручну форматували й нормалізували.
- Готовий результат надсилали ініціатору запиту.
Типовий запит забирав у середньому 2–3 години роботи фахівця.
Саме виконання запиту до бази було лише частиною роботи. Час ішов і на те, щоб розібратися в запиті, підготувати фільтри, вибрати поля, структурувати результат, нормалізувати дані та передати їх ініціатору.
Через це виникало кілька проблем із виконанням.
Під час планування спринтів операційні запити конкурували із завданнями з розробки продукту й автоматизації, а технічні фахівці раз за разом виконували схожі операції вибірки замість того, щоб займатися розробкою.
Крім того, бізнес-користувачі не могли отримати результат одразу, навіть якщо запит відповідав уже відомому шаблону.
Особливо неефективним процес був для великих вхідних файлів. Запит на кілька тисяч доменів усе одно міг потребувати годин підготовки й ручної обробки результату.
Обстеження процесів і визначення обсягу робіт
Ми розглядали це як проблему операційного процесу, а не бази даних.
Мета була чіткою: прибрати повторювану роботу з вибірки даних із черги розробки й при цьому не відкривати користувачам необмежений доступ до бази даних.
Під час первинного аналізу ми виявили кілька типів запитів, що постійно повторювалися:
- Вибірка записів за заздалегідь визначеними фільтрами.
- Обробка вхідного файлу з доменами або prooflink.
- Повернення лише вибраних полів.
- Підрахунок відповідних записів у базі даних.
- Формування випадкової вибірки.
- Експорт результатів у CSV або Excel.
- Створення структурованої папки з результатами та чіткий статус виконання.
Перший реліз зосередився саме на цих повторюваних шаблонах. Нестандартні аналітичні запити та зміни в базі даних залишилися поза межами автоматизації й, як і раніше, потребували технічного розгляду.
Так рішення залишалося контрольованим і водночас охоплювало операції, на які припадала більшість повторюваної роботи.
Рішення
Ми створили RPA DB Assistant на базі UiPath Assistant, який запускається гарячими клавішами.
Бот працює як керований робочий інструмент для вибірки даних. Користувачі запускають заздалегідь визначені операції, не пишучи запитів до бази даних і не працюючи безпосередньо з її структурою.
Реалізована операційна модель включає:
- F2 – Загальна вибірка за запитом: вибирає дані з таблиць LinkedIn, ZoomInfo або Yahoo Finance та експортує результат у CSV.
- F3 – Вибірка за вхідним файлом: приймає домени або prooflink із вхідного файлу й повертає відповідні записи в CSV або Excel.
- Alt+F2 – Інформаційний запит: рахує записи в базі даних і формує випадкові вибірки.
Також бот створює потрібні папки, відкриває папку з результатом і повідомляє статус виконання. Саме ці функції задокументовано як основну операційну модель RPA DB Assistant.
Структура рішення
| Блок рішення | Що реалізували | Операційний результат |
|---|---|---|
| Взаємодія з користувачем | Робочий процес у UiPath Assistant із запуском гарячими клавішами | Користувачі запускають керовані операції без знання бази даних |
| Загальна вибірка з бази даних | Визначені запити до трьох таблиць із даними про компанії | Більше не потрібно щоразу вручну готувати запити |
| Масова обробка файлів | Вибірка за доменами та prooflink із вхідних файлів CSV або Excel | Великі запити виконуються як одна автоматизована операція |
| Обробка вибраних полів | Логіка, що повертає лише потрібні поля | Швидша робота без зайвої обробки |
| Підрахунок і вибірки | Автоматичні функції підрахунку записів і випадкової вибірки | Типові перевірочні запити більше не потребують технічних фахівців |
| Стандартизація результату | Автоматичне формування файлів CSV та Excel | Більшість ручного форматування й нормалізації зникла |
| Керування папками | Автоматичне створення та відкриття папок із результатами | Результати завжди передаються в однаковому вигляді |
| Звітність про виконання | Статус виконання в середовищі UiPath | Прозорість щодо завершення та збоїв |
Як проходило впровадження
Ми реалізували рішення у три чітко визначені етапи.
Січень — початкова розробка
Першу робочу версію реалізували за двотижневий спринт.
Перша версія охоплювала основні сценарії вибірки й дала користувачам перший інтерфейс самообслуговування. Пріоритетом було якнайшвидше вивести типові запити з ручного виконання через спринти.
Березень — рефакторинг
Після першого періоду використання ми провели рефакторинг рішення.
Основні цілі були такі:
- Спростити внутрішню структуру робочих процесів.
- Спростити підтримку рішення.
- Уніфікувати роботу з різними таблицями бази даних.
- Покращити логіку обробки фільтрів і полів.
- Підготувати бота до більших обсягів вхідних даних.
- Зменшити зусилля на додавання нових полів і сценаріїв вибірки.
Ми не розглядали рефакторинг як окрему перебудову з нуля. Він спирався на поведінку першої версії та реальні операційні запити, що надходили після запуску.
Травень — оптимізація продуктивності
Останній етап був присвячений обробці великих обсягів.
Головним вузьким місцем була логіка обробки вибраних полів. Великі запити могли містити тисячі записів, тоді як користувачам зазвичай була потрібна лише певна частина полів.
Ми впровадили новий клас для обробки вибраних полів і налаштували алгоритм на великих обсягах даних.
Після оптимізації:
- Повний сценарій на 5 000 доменів виконувався за 10 секунд.
- Найскладніший компонент обробки вибраних полів займав чотири секунди.
- Алгоритм залишався стабільним на великих запитах.
Такий поетапний підхід дав змогу швидко отримати бізнес-цінність і вже потім покращувати архітектуру та продуктивність, спираючись на реальне використання, а не на припущення.
Технологічний стек
| Рівень | Технологія | Призначення |
|---|---|---|
| Інтерфейс користувача | UiPath Assistant | Запуск робочих процесів гарячими клавішами |
| Автоматизація | UiPath | Вибірка, обробка файлів, нормалізація та експорт |
| Оркестрація | UiPath Orchestrator | Розгортання, керування пакетами та статус виконання |
| База даних | База даних компанії | Зберігання та вибірка інформації про компанії |
| Таблиця даних | Таблиця LinkedIn | Інформація про компанії та профілі |
| Таблиця даних | Таблиця ZoomInfo | Інформація про компанії та фірмографічні дані |
| Таблиця даних | Таблиця Yahoo Finance | Інформація про публічні компанії та фінансові дані |
| Вхідні дані | CSV та Excel | Списки доменів і prooflink |
| Результат | CSV та Excel | Структурована передача результатів |
Результати
| Показник | До | Після | Результат |
|---|---|---|---|
| Час обробки тестового запиту на 5 000 доменів | 2–3 години | 10 секунд | Приблизно у 800 разів швидше |
| Трудовитрати на типовий запит | 2–3 години роботи фахівця | Лише запуск і перевірка результату | До 2–3 годин економії на кожному запиті |
| Пропускна здатність | Ручна підготовка запиту й експорт | 5 000 доменів за 10 секунд | Близько 500 доменів на секунду в тестовому сценарії |
| Складна обробка вибраних полів | Залежала від ручного запиту та структури експорту | 4 секунди | Стабільна обробка великих обсягів |
| Прийом запитів | Потрібне планування у спринт | Доступно на вимогу | Типові запити прибрано з черги розробки |
| Охоплення користувачів | Залежність від технічних фахівців | Підтримка 10–15 користувачів | Контрольований доступ у режимі самообслуговування |
| Підготовка результату | Окремі вивантаження й ручна нормалізація | Стандартизований результат у CSV або Excel | Ручну підготовку результату здебільшого прибрано |
| Охоплення джерел даних | Окрема ручна робота для кожного джерела | Три підтримувані таблиці бази даних | Єдиний процес для користувача |
Співвідношення між 2–3 годинами та 10 секундами дає розрахунковий діапазон від 720 до 1 080 разів. Ми використовуємо округлене значення — приблизно у 800 разів швидше.
Місячну та річну економію трудовитрат не розраховували, оскільки кількість запитів на місяць була невідома. Тому підтверджену економію наведено в розрахунку на один запит, без екстраполяції.
Хочете побачити, які запити у вашій команді можна виконувати так само? Забронюйте безкоштовний розбір процесів.
Що виявилося складним
Обробка полів на великих обсягах
Найсерйознішим технічним викликом була обробка великих наборів результатів, коли потрібно повертати лише ті поля, які запросив користувач.
Перша реалізація працювала на стандартних обсягах, але потребувала оптимізації для більших файлів і складніших комбінацій полів.
Ми розв’язали це завдяки рефакторингу в березні та новому класу обробки вибраних полів, упровадженому на етапі оптимізації в травні. Найскладнішу частину алгоритму вдалося скоротити до чотирьох секунд.
Різні структури баз даних
Таблиці LinkedIn, ZoomInfo та Yahoo Finance мають різну структуру й різні набори полів.
Окрема реалізація для кожного джерела означала б три окремі рішення та більші витрати на підтримку. Натомість ми відокремили логіку вибірки, специфічну для кожного джерела, від спільних компонентів обробки, експорту, керування папками та звітності про статус.
Контрольований доступ
Автоматизація мала зменшити залежність від розробників, не відкриваючи необмеженого доступу до бази даних.
Модель із гарячими клавішами розв’язала це завдання: користувачі отримали доступ лише до підтримуваних операцій вибірки. Логіка запитів, робота з підключеннями та обробка, специфічна для бази даних, залишилися всередині автоматизації.
Вплив на операційну роботу
Головний результат — не лише швидше виконання запитів.
Проєкт змінив модель відповідальності за процес.
До впровадження стандартизована вибірка даних вважалася роботою розробки. Після впровадження вона стала частиною операційної роботи.
Це дало три прямі переваги:
- Розробники перестали витрачати по кілька годин на запити з вибірки й експорту.
- Користувачі отримували результати, не чекаючи планування спринту.
- Компанія отримала структуру, яку можна повторно використовувати для додавання нових таблиць, полів і типових сценаріїв вибірки.
Рішення також зробило виконання передбачуванішим. Типові запити більше не залежали від поточного навантаження спринту чи доступності конкретного технічного фахівця.
Що це означає для схожих бізнесів
Такий підхід актуальний для компаній, які вже мають централізовані дані, але досі залежать від розробників, коли потрібно отримати типові дані.
Типові ознаки:
- Стандартні вивантаження оформлюються як завдання для розробки.
- Інженери раз за разом готують схожі запити до бази даних.
- Користувачі надсилають списки доменів, компаній, ID або prooflink для збагачення даних.
- Результати потребують ручної підготовки в CSV або Excel.
- Сам запит до бази виконується швидко, але повна обробка звернення триває години.
- Операційна робота регулярно перериває заплановану розробку.
Замість того щоб автоматизувати всі можливі запити до бази даних, правильніше почати з того, щоб виявити шаблони запитів, що повторюються, визначити формати вхідних і вихідних даних та автоматизувати лише ті операції, які можна виконувати стабільно.
У цьому проєкті першу робочу версію реалізували за два тижні. Рефакторинг та оптимізацію продуктивності провели вже потім, на основі реального використання та тестування на великих обсягах.
Як 2BBooster допомагає з подібними проєктами
Для подібних проєктів із доступу до даних і внутрішньої автоматизації наш підхід включає:
- Картування поточного процесу запитів і погоджень.
- Вимірювання реальних ручних зусиль на один запит.
- Відокремлення повторюваних операцій від нестандартної аналітичної роботи.
- Визначення сценаріїв керованого доступу.
- Створення першої робочої версії навколо найчастіших сценаріїв.
- Тестування рішення на файлах реального розміру.
- Рефакторинг на основі фактичного використання.
- Додавання моніторингу, структурованих результатів і закріплення відповідальності за підтримку.
Пов’язані послуги:
- Роботизована автоматизація процесів (RPA)
- Консалтинг з оптимізації та автоматизації робочих процесів
Часті запитання
Скільки тривав проєкт?
Першу робочу версію реалізували за двотижневий спринт.
Чи потрібен був користувачам прямий доступ до бази даних?
Ні. Користувачі працювали через заздалегідь визначені функції UiPath Assistant. Доступ до бази даних і логіка запитів залишалися всередині автоматизації.
Які операції автоматизували?
Бот підтримував загальну вибірку за запитом, обробку вхідного файлу з доменами або prooflink, вибір окремих полів, підрахунок записів у базі даних, випадкову вибірку та експорт у CSV або Excel.
Скільки користувачів працювали з ботом?
10–15 внутрішніх користувачів мали доступ до підтримуваних функцій вибірки.
Як бот працював на великих запитах?
У підтвердженому тестовому сценарії близько 5 000 доменів обробили за 10 секунд. Найскладніший компонент обробки вибраних полів займав чотири секунди.
Чи зникла потреба в технічних фахівцях?
Для стандартизованих запитів на вибірку технічні фахівці більше не потрібні. Нестандартна аналітика, нові структури баз даних і непідтримувані типи запитів, як і раніше, потребують технічного розгляду.
Висновок
DB Assistant перетворив технічний запит, що залежав від спринтів, на контрольований процес самообслуговування.
Першу версію реалізували за два тижні. Рефакторинг та оптимізація продуктивності підготували рішення до роботи з великими обсягами в продакшені.
Для підтвердженого сценарію на 5 000 доменів час обробки скоротився з 2–3 годин до 10 секунд. Це приблизно 800-кратне прискорення та до 2–3 годин роботи фахівця, заощаджених на кожному типовому запиті.
У підсумку компанія отримала швидший доступ до даних, меншу залежність від розробки, стабільні результати та структуру, яку легко підтримувати й розширювати під нові операційні сценарії.
Стандартні запити до бази даних не мають проходити через розробку
Якщо ваша команда досі проводить типові вивантаження з бази, пошук даних, збагачення чи звітні завдання через планування спринтів, найчастіше це очевидна можливість для автоматизації.
Ми можемо описати поточний процес запитів, визначити, які операції повторюються, і показати, як може виглядати стабільний шар самообслуговування навколо ваших наявних баз даних та інструментів.
Забронюйте безкоштовний розбір процесів, щоб визначити, які запити до бази даних варто першими прибрати з черги розробки.
Читайте також
Стратегія оптимізації хмари: як узяти під контроль витрати на хмарні сервіси
Управління витратами на хмару — головний виклик для більшості організацій. Повернути контроль допоможуть чотири практики: моніторинг використання, rightsizing, знижки за зобов’язання та контроль витрат.