Почему 65% времени data scientists уходит впустую и как вернуть 2.1 млн ₽/мес
Игорь открыл таблицу в понедельник утром и увидел то, что видел каждую неделю: четыре senior data scientist чистят чужие экселевки и пишут скрипты, которые выбросят через месяц. Не строят модели — чистят данные. Снова.
65% рабочего времени команды уходит на подготовку данных и одноразовые ETL-скрипты. Это не гипотеза — это цифра, которую получаешь, если честно посчитать. Пока люди заняты рутиной, восемь-десять проектов в месяц уплывают к конкурентам. Каждый — по 180 тысяч рублей. Плюс двое сотрудников на полной ставке, которые делают только это. Итого: больше двух миллионов рублей в месяц компания теряет не из-за плохих специалистов, а из-за того, как устроен процесс.
Хорошая новость: это не проблема найма. Это проблема архитектуры — и она решается.
Стоимость автоматизации ETL-пайплайна для data science компании: что нужно знать до старта
Когда владелец или директор data science компании спрашивает «сколько стоит автоматизация ETL-пайплайна», ответ зависит от трёх вещей: сколько у вас источников данных, насколько они грязные, и что происходит после очистки. Разберём коротко - и перейдём к живому кейсу.
Три уровня автоматизации ETL - и три ценовых диапазона:
- Базовый (no-code коннекторы, 15-40 тыс ₽/мес). Albato, Make, n8n. Работает, если источников 2-4 и данные более-менее чистые. С параллельными тяжёлыми задачами и нетривиальными трансформациями не справляется.
- Средний (облачные ETL-платформы, 60-150 тыс ₽/мес). Fivetran, Stitch, Airbyte. Хорошо для стандартных коннекторов, но при масштабировании дорожает быстро, а с кастомизацией - туго.
- Enterprise-grade (собственная оркестрация, разовое внедрение 150-300 тыс ₽ + сервер). Apache Airflow + PostgreSQL. Нужен, если у вас 10+ data scientists, нестандартные источники вроде российских CRM (например, МойСклад) и важна полная прозрачность того, что происходит с данными. Именно этот путь мы выбрали для клиента из этого кейса.
На что смотреть при выборе: сколько пайплайнов работает параллельно, нужна ли запись обратно в источник (write-back), есть ли в стеке нестандартные российские сервисы. Если хотя бы два пункта из трёх - да, no-code инструменты не потянут. Дальше - конкретный кейс о том, как мы это делали для петербургской компании.
Контекст клиента
К нам обратился Игорь, директор по развитию data science компании из Санкт-Петербурга. 28 человек в штате: 12 data scientists, 8 аналитиков, 8 в поддержке. Оборот - 18 млн ₽/мес. Клиенты - retail и e-commerce компании, которым нужен анализ продаж, прогнозирование спроса, сегментация покупателей.
Специфика ниши такая: клиентские данные живут в МойСклад - российской системе учёта товаров и заказов. Каждый новый проект начинался одинаково: data scientist вручную выгружал данные из МойСклад в Excel, чистил их, писал одноразовый Python-скрипт под конкретного клиента - и только после этого начиналась реальная аналитическая работа.
Что у них болело (в цифрах)
Игорь пришёл с конкретной болью: команда растёт, а проекты идут медленнее. Когда мы разобрали, куда уходит время, картина оказалась предсказуемой и довольно грустной.
65% рабочего времени data scientists уходило на подготовку данных - выгрузки, чистку, написание одноразовых ETL-скриптов. На реальную аналитику, за которую клиенты платят деньги, оставалось 35%.
Конкретные цифры до внедрения:
- Типовая ETL-задача (выгрузка + чистка + трансформация): 16 часов
- Автоматизированных операций подготовки данных: 8% - то есть почти всё вручную
- Проектов на одного senior data scientist: 3.2 - больше физически не вмещалось
- Средний срок сдачи проекта: 24 дня (хотя клиентам обещали 14)
- Текучка в команде: 35%/год - люди уходили, потому что вместо интересных задач занимались копипастой скриптов
В деньгах это выглядело так: из-за задержек компания упускала 8-10 проектов в месяц. При среднем чеке 180 тыс ₽ - это 1.4-1.8 млн ₽ недополученной выручки ежемесячно. Плюс два фулл-тайм сотрудника (≈700 тыс ₽/мес в зарплатах) фактически занимались только рутинными выгрузками.
«По словам Игоря, главное было не автоматизация ради автоматизации - главное, чтобы ребята перестали ненавидеть понедельники из-за очередного Excel с данными клиента».
Что мы предложили - наш стек и стоимость автоматизации ETL-пайплайна для data science компании
Остановились на трёх инструментах. Вот почему именно они - и во сколько это обошлось.
Apache Airflow
Система оркестрации задач с открытым исходным кодом. Позволяет описывать пайплайны обработки данных как код, запускать их по расписанию или по событию, отслеживать статус каждого шага в веб-интерфейсе. Подходит командам от 5+ data scientists, где нужно запускать десятки параллельных задач без ручного контроля. Лицензия бесплатная (open source), но нужен сервер - от 8-15 тыс ₽/мес на облачной инфраструктуре. Минусы: требует настройки и поддержки (нельзя просто «включить»), порог входа для новых разработчиков выше, чем у no-code решений.
PostgreSQL
Надёжная реляционная база данных с открытым исходным кодом. Для этого клиента - центральное хранилище: сюда приходят сырые данные из МойСклад, здесь происходят трансформации, отсюда data scientists забирают готовые витрины данных. Бесплатно, хостинг - от 5 тыс ₽/мес. Минусы: не подходит для очень больших объёмов (петабайты) - там нужен ClickHouse или что-то аналогичное, требует администрирования.
МойСклад
Российская система управления торговлей и складом. Клиенты data science компании хранят там данные о продажах, остатках, заказах - именно оттуда нужно было тянуть данные для анализа. У МойСклад есть полноценный API, что позволило нам не только читать данные, но и записывать обратно результаты анализа - например, статусы проектов. Тарифы - от 1 500 до 6 900 ₽/мес в зависимости от числа пользователей. Минусы: лимит 45 запросов в секунду на аккаунт (при больших объёмах нужна очередь), вложенные запросы работают медленнее.
Бюджет проекта
| Статья | Стоимость |
|---|---|
| Работа FlowFrame (настройка, интеграция, тесты) | 220 тыс ₽ (разово) |
| Сервер для Airflow + PostgreSQL | 12-15 тыс ₽/мес |
| МойСклад (уже был у клиента) | 0 доп. затрат |
| Итого первый месяц | ≈235 тыс ₽ |
| Ежемесячно далее | ≈15 тыс ₽ |
При росте выручки на 2.1 млн ₽/мес окупаемость наступила за первые две недели после запуска.
Как мы это внедряли (шаги по неделям)
День 1-3: аудит и картирование
Первые два дня провели с командой: попросили каждого data scientist показать, как именно он начинает новый проект. Выяснилось, что у 12 человек было 12 разных способов выгружать данные из МойСклад - кто в Excel, кто через браузер, кто через самописный скрипт. Никакой стандартизации. Зафиксировали все типовые операции и выделили 8 паттернов, которые повторялись в 80% проектов.
День 4-7: базовая инфраструктура
Развернули Airflow и PostgreSQL на облачном сервере. Настроили подключение к МойСклад через защищённый токен. Создали staging-схему в PostgreSQL - отдельное место, куда попадают сырые данные до трансформации. Подключили к Airflow внутреннюю учётную запись МойСклад клиента.
День 8-14: три основных пайплайна
Написали три DAG (сценария автоматизации):
- Первый - каждые 15 минут проверяет МойСклад на новые данные и загружает их в PostgreSQL. Инкрементально: только то, что изменилось с последнего запуска.
- Второй - каждый час запускает стандартные трансформации: очистка дублей, приведение форматов дат, нормализация названий товаров. То, на что раньше data scientist тратил 5-7 дней вручную.
- Третий - записывает обратно в МойСклад статусы проектов и кастомные метрики качества данных. Игорь и менеджеры видят прогресс в привычном интерфейсе, не заходя в Airflow.
День 15-21: тестирование и обучение
Прогнали 5 реальных проектов через новые пайплайны параллельно со старым способом - сравнивали результаты. Расхождений не нашли, зато разница во времени была очевидна. Провели два обучающих сессии для команды: одну для data scientists (как работать с готовыми витринами данных), одну для менеджеров (как смотреть статусы в МойСклад). Игорь подключился лично - хотел понять, что происходит «под капотом».
Что получили в цифрах
| Метрика | До | После |
|---|---|---|
| % автоматизированных операций подготовки данных | 8% | 72% |
| Время на типовую ETL-задачу | 16 часов | 2.5 часа |
| Проектов на одного senior | 3.2 | 5.1 |
| Средний срок сдачи проекта | 24 дня | 14 дней |
| Текучка в команде | 35%/год | 12%/год |
| Выручка (прирост) | - | +2.1 млн ₽/мес |
ROI посчитать несложно: 235 тыс ₽ разово + 15 тыс ₽/мес на инфраструктуру против прироста выручки в 2.1 млн ₽/мес. Окупаемость - первые 3-4 недели после запуска. Отдельный эффект: два сотрудника, которые раньше занимались только рутинными выгрузками, переключились на аналитические задачи - это ещё ≈700 тыс ₽/мес высвобожденного ФОТ в пересчёте на полезную работу.
Снижение текучки с 35% до 12% - это примерно 2-3 человека в год вместо 4-5. Если учесть стоимость найма и онбординга data scientist (от 200 тыс ₽ на одного), получается ещё 400-600 тыс ₽ экономии ежегодно.
Что бы мы сделали иначе
1. Начали бы с аудита источников данных раньше. Мы потратили лишние 2 дня на то, чтобы разобраться, какие поля в МойСклад у каждого клиента заполнены по-разному. Лучше было запросить у команды список нестандартных полей ещё на этапе переговоров - сэкономили бы время на переписывание части трансформаций.
2. Раньше подключили бы менеджеров, не только data scientists. Мы сфокусировались на технической команде и только на третьей неделе показали Игорю и менеджерам, как читать статусы в МойСклад. Оказалось, у менеджеров были свои ожидания от интерфейса - пришлось доработать отображение статусов. Включи мы их на первой неделе, сэкономили бы 3 дня.
3. Настроили бы алёрты на сбои пайпл
Что делать прямо сейчас
Если вы узнали в этой истории свою команду — не откладывайте на квартальное планирование. Вот четыре шага, которые можно сделать сегодня:
- Попросите одного data scientist честно залогировать рабочий день. Не по памяти, а реально — что и сколько времени заняло. Обычно результат неприятно удивляет уже на первый взгляд.
- Посчитайте стоимость одного часа вашей команды. Умножьте суммарный ФОТ data scientists на долю рутинных задач — получите цифру, с которой удобно разговаривать с финансовым директором.
- Составьте список источников данных, с которыми работает команда. Сколько из них подключены вручную? Где нет мониторинга сбоев? Это и есть точки потерь.
- Определите одну задачу, которую команда повторяет каждую неделю. Именно с неё стоит начинать автоматизацию — быстрый результат даёт мотивацию двигаться дальше.
Когда зовут нас
FlowFrame занимается именно такими ситуациями: когда сильная команда тонет в рутине, а бизнес не получает от неё того, за что платит. Мы не продаём «цифровую трансформацию» — мы разбираемся в конкретном пайплайне и предлагаем конкретное решение.
Если хотите прикинуть, сколько теряет именно ваша команда, — загляните на сайт и напишите нашему AI-боту. Он задаст несколько вопросов и поможет сориентироваться ещё до звонка.