Привет! Меня зовут Дмитрий Гаврилов, я руководитель центра компетенции аналитики в MWS. Моя команда внедряет ИИ‑скиллы в работу дата‑аналитиков. Мы посмотрели на типичный рабочий день и поняли: рутина съедает до 75% времени аналитика. А можно ли это передать ИИ‑агенту без потери качества? Эту гипотезу проверили на реальных задачах и получили конкретные результаты — делюсь в этом материале.
Какие рутинные задачи съедают время аналитика
Давайте заглянем в типичный рабочий день дата‑аналитика, который создает витрину данных. Вот как выглядит этот процесс в традиционном подходе.
Все начинается с эпика в Jira. Аналитик получает задачу, но ТЗ там обычно размытое. Начинаются уточнения: беготня к заказчику, вопросы‑расспросы, попытки вытащить из бизнеса внятные требования. Заказчик, естественно, не очень всем этим доволен. Дальше аналитик создает различные артефакты прототипа (спецификацию, скрипт прототипа, DDL, всё это согласует с naming convention и так далее) — чаще всего всё это по опыту, по памяти. Кто‑то пишет сразу и сам, а новички идут к сеньорам что‑то уточнять и тратят не только своё время, но и время дорогостоящих сотрудников.
Потом начинается поиск шаблонов в Confluence. Проблема в том, что шаблоны бывают и устаревшие, кто‑то их поддерживает в актуальном состоянии, а кто‑то и нет. После этого аналитик вручную выписывает требования из описания задачи, согласовывает документацию с командой, прОдактом и дата‑стюардами. И, наконец, исправляет ошибки после код‑ревью.
Вот как по нашим подсчетам распределяется рабочее время аналитика в течение дня:
Поиск информации — 25% времени. Аналитик ищет нужные данные в Jira, Confluence, опросах коллег.
Создание документации — 30%. Это DDL‑скрипты, бизнес‑требования, описание спецификаций, прототип
Согласование и правки — 20%. Согласование с командой, дата‑стюардами, прОдактом, исправление замечаний после ревью.
Непосредственно анализ и проектирование — только 25%. Именно здесь задействован аналитик своими мозгами, его критическое мышление и экспертиза.
То есть лишь четверть рабочего дня аналитик тратит на действия, которые действительно требуют его квалификации. Все остальное — поиск, оформление, согласование. И именно здесь возникает вопрос: можно ли эту работу передать ИИ? Если да, то какие инструменты — скиллы — для этого нужны?
Что такое скиллы в нашей истории
Когда мы говорим про ИИ в контексте работы аналитика, то это не про «дал задачу нейронке и получил результат». Мы про системное решение, которое необходимо масштабировать и использовать многократно.
В нашем случае скилл — это не типичный промпт, а сохраненный, многократно используемый сценарий работы нейросети для конкретного типа задач ИИ‑агента. У такого сценария есть:
четкое описание роли и задачи (кто исполняет, что должен сделать);
пошаговый алгоритм выполнения (в какой последовательности действовать);
требования к входным и выходным данным (что подаем на вход, что должны получить);
примеры и шаблоны (нейросеть понимает, как должен выглядеть результат).
Скилл — это полноценная рабочая инструкция для ИИ‑агента. Он не просто отвечает на вопрос — он выполняет последовательность действий, взаимодействует с корпоративными системами, создает артефакты.
И здесь важный момент: скилл существует не сам по себе. Он работает в связке с ИИ‑агентом, который исполняет сценарий, и с MCP‑сервером, который обеспечивает доступ к системам.
Что такое MCP‑сервер? Это драйвер — прослойка между агентом и корпоративными системами. Он позволяет агенту подключаться к Jira, Confluence, GitLab, базам данных, API и другим источникам. Без MCP‑сервера агент просто не увидит данные, которые ему нужны для работы. С ним — он может читать задачи, вытаскивать шаблоны, проверять правила нейминга, сохранять результаты. Все централизованно, через единый интерфейс.
И еще один важный нюанс: один агент может владеть несколькими скиллами, а один скилл может использоваться разными агентами. Это как библиотека функций, где каждая функция умеет делать что‑то конкретное, и ты вызываешь ее по мере необходимости.
Для чего мы ИИзировали работу аналитика
Мы внедряли ИИ‑инструменты в работу дата‑аналитиков и параллельно замеряли эффект. Получили ощутимые бонусы:
Скорость. ИИ пишет быстро. Он создает не просто текст, а структурированные артефакты, которые можно сразу использовать: DDL‑скрипты, YAML‑спецификации, бизнес‑требования по шаблону. Время на их создание сокращается в 3–5 раз, а в некоторых задачах — и в 20 раз. Наши разработки уже демонстрируют такие результаты: на создание бизнес‑требований уходит 30 минут вместо 8 часов вручную.
Консистентность. Разные аналитики могут по‑разному оформлять документы. У каждого свой стиль, свои предпочтения. Кто‑то любит таблицы, кто‑то — списки, кто‑то — подробные описания. С использованием ИИ все артефакты создаются по единому шаблону. Это упрощает и чтение, и дальнейшую автоматизацию.
Масштабируемость. Один аналитик, освобожденный от рутины, может параллельно вести несколько проектов. При этом качество не страдает — рутинную работу делает ИИ, а аналитик контролирует результат.
Качество. Люди ошибаются. Мы все знаем, как непросто найти ошибку в DDL или в маппинге полей. ИИ, если его правильно настроить, совершает меньше таких ошибок. Да, он тоже может ошибаться — галлюцинации никто не отменял. Но мы можем заставить его учиться, проверять свои же результаты, и постепенно ошибок становится меньше.
Онбординг. Это неочевидный, но очень важный пункт. Новый сотрудник, используя агентов и их скиллы, сразу начинает понимать, как устроены процессы. Он видит шаблоны, видит результат, который должен получиться, и учится на практике. Ему не нужно сидеть рядом с сеньором и запоминать, как правильно оформлять бизнес‑требования. Он просто запускает скилл и видит эталон.
Мы прикинули ROI автоматизации для команды из пяти аналитиков:
Экономия времени в расчете на одну задачу составила около 75%. В неделю мы экономим примерно 75 часов. В месяц — это 300 часов. Фактически мы получаем двух дополнительных сотрудников без увеличения штата. Тест шел на конкретных задачах, и вероятно, на других цифры могут отличаться. Но то, что на наших реальных кейсах ИИ показал такую эффективность, заставляет как минимум задуматься.
Какие процессы можно автоматизировать, а какие нет
Мы разбили все задачи аналитика на три категории по степени автоматизируемости.
Полностью автоматизируемые (80%+ через ИИ)
Это задачи, которые выполняются по четкому алгоритму, имеют структурированный вход и выход, и для которых есть готовые шаблоны:
Извлечение требований из Jira и Confluence. Скилл читает эпик и связанные задачи, вытаскивает всю нужную информацию.
Генерация DDL по шаблону. ИИ создает скрипты с техническими полями, комментариями и описаниями.
Создание CSV‑ и YAML‑спецификаций. Машиночитаемые форматы для других агентов.
Проверка соответствия правилам нейминга. Если у вас описаны правила, ИИ проверит, все ли им соответствует.
Поиск аналогичных витрин в репозитории. Чтобы не изобретать велосипед, если что‑то полезное уже было сделано.
Частично автоматизируемые (50–80% через ИИ)
Здесь результат требует проверки и доработки человеком:
Создание бизнес‑требований по шаблону. ИИ генерирует структурированный документ, но его нужно сверить с исходным ТЗ.
Маппинг полей источник‑таргет. ИИ предлагает маппинг, но аналитик проверяет, все ли корректно.
Анализ гэпов в данных. ИИ подсвечивает, где есть нестыковки, но финальное решение остается за человеком.
Генерация тестовых данных. Синтетика генерируется без проблем, но с точки зрения безопасности нужно проверять, что сделал ИИ.
Требуют участия человека (<50% через ИИ)
Здесь ИИ может только помочь:
Согласование требований с бизнесом. С заказчиком надо разговаривать, уточнять, погружаться в детали. ИИ здесь не помощник. Мы пытались внедрить ИИ для подобного общения — для сбора требований, для уточнения размытых ТЗ. Но бизнес говорит на своем языке, у разных команд сильно отличаются подходы, и ИИ пока не может привести это к единому знаменателю.
Принятие архитектурных решений. Архитектура — это деньги, это долгосрочные последствия. Здесь точно нужен человек.
Приоритизация задач. ИИ не всегда знает, кто в команде больше загружен, у кого сейчас аврал, а кто уже все сделал. Этот процесс координации для аналитика.
Интерпретация бизнес‑контекста. Бизнес может сформулировать задачу так, что ни один ИИ не разберется без подсказок и разъяснений.
Ключевой принцип, который мы для себя вывели: ИИ — это инструмент усиления аналитика, а не его замена. Он забирает на себя шаблонную, повторяемую, структурированную работу. Все, что требует креативности, переговоров с бизнесом и принятия решений, остается за человеком.
Как мы определяем, что задачу можно автоматизировать
Мы определили четыре критерия. Если задача им соответствует — ее можно смело передавать ИИ.
Повторяемость. Задача выполняется по одному алгоритму. Если вы каждый раз делаете одно и то же — это кандидат на автоматизацию.
Структурированность. Входные данные имеют понятный формат. Вы знаете, что подаете на вход, и знаете, что хотите получить на выходе.
Документированность. Есть четкие правила и шаблоны. Если вы не можете однозначно описать процесс — ИИ тем более его не выполнит.
Проверяемость. Вы можете определить критерии качества. Если вы не знаете, как проверить результат — не поймете, работает ИИ или нет.
Если хотя бы один из критериев не выполняется — лучше не автоматизировать. Там, где есть неоднозначность или где сложно измерить результат, человек справится лучше.
Наши скиллы, которые уже работают
Мы реализовали скиллы, и я покажу два основных. Они закрывают бóльшую часть рутины в процессе Source‑to‑Target — это создание витрин данных от получения ТЗ до готового артефакта.
Оба скилла работают через MCP‑сервер, который обеспечивает интеграцию с Jira, Confluence и GitLab. То есть агент сам ходит в системы, читает данные, сохраняет результаты — без участия человека на каждом шагу.
Скилл № 1: S2T‑process‑BR‑creator
На весь процесс уходит 30 минут вместо 8 часов ручной работы.
Скилл № 2: S2T‑process‑PHDM‑creator
Эти два скилла работают в связке. Можно запустить их по отдельности, а можно построить последовательность: сначала BR‑creator формирует бизнес‑требования, затем PHDM‑creator на их основе строит физическую модель. Контекст передается от одного скилла к другому — получается настоящий конвейер, где каждый этап использует результаты предыдущего.
Как оцениваем качество работы скиллов
Мы составили трехуровневую систему оценки. Без нее сложно понять, работает ИИ или просто выдает красивый текст.
1 уровень — валидация формата
Это самая базовая проверка. Мы смотрим, что:
Все выходные файлы созданы (не пропущены).
YAML и CSV валидны — парсятся без ошибок.
DDL синтаксически корректен (можно запустить в базе данных).
Если этот уровень не пройден — дальше можно не смотреть. Ошибка в формате делает результат бесполезным.
2 уровень — проверка консистентности
Здесь мы проверяем, что результат соответствует правилам:
Имена полей соответствуют правилам нейминга из Confluence.
Все обязательные технические поля добавлены (дата создания, дата обновления, флаги и тому подобное).
Маппинг на источники полный — нет полей без source.
Если на этом уровне обнаруживаются проблемы — их легче исправить, чем если бы их пытался искать вручную сам аналитик.
3 уровень — бизнес‑валидация
Это самая сложная проверка. Она требует понимания бизнес‑контекста:
Требования из эпика полностью отражены в бизнес‑требованиях.
Критерии приемки измеримы и тестируемы.
Use Cases покрывают основные сценарии использования.
Здесь без человека не обойтись. Но ИИ помогает: он уже подготовил структуру, осталось проверить, что ничего не пропущено.
Для каждого скилла мы подготовили метрики качества:
К заявленным целевым значениям мы постоянно стремимся, и результаты нас устраивают.
Бенчмаркинг на реальных данных
Мы замеряли время на выполнение задач до и после внедрения ИИ. Раньше на создание бизнес‑требований уходило минимум 8 часов, а чаще больше — особенно если нужно было перепроверять информацию, уточнять у коллег, искать забытые артефакты. Теперь — полчаса, а то и меньше.
Качество выполнения тоже не уступает. В этом плане мы сравнивали результаты, которые получали аналитики вручную, с тем, что генерируется автоматически. ИИ выдает структурированные и полные документы — если, конечно, на вход подано хорошее ТЗ. Результаты наших тестов ниже:
Для постоянного мониторинга качества мы используем:
Еженедельный аудит. Выборочно проверяем 5% артефактов — смотрим, насколько они соответствуют требованиям.
Сравнение с эталоном. У нас есть примеры, которые аналитики сделали вручную. Периодически прогоняем их через ИИ и сравниваем результаты.
Обратная связь от команды. Собираем мнение после каждого спринта — чтобы понимать, где скиллы работают хорошо, а где нуждаются в доработке.
Версионирование скиллов. Отслеживаем изменения в описаниях скиллов, чтобы видеть, как они эволюционируют, и вовремя замечать, не ломают ли нововведения старые процессы.
Как начать использовать скиллы
Если вы хотите попробовать то же самое, процесс максимально простой.
Клонировать репозиторий:
git clone git@gitlab.services.*****:andq/ai/skills.git
Запустить MCP‑сервер:
cd "devtools/MCP-configs" node mcp-server.js
Активировать скилл в ИИ‑агенте:
@S2T-process-PHDM-creator jira_epic_key="BDL-XXXXX"
Проверить результат:docs/
Что у нас в планах
Скиллы уже показывают результат, но мы намерены развивать систему дальше — вот ключевые направления:
Поддержка дата‑каталога. Мы хотим добавить интеграцию с DataCatalog и DataContract — чтобы все метаданные о витринах хранились централизованно и были доступны для других агентов.
Автоматическая валидация DDL. Сейчас DDL мы проверяем вручную. Это можно автоматизировать: запускать сгенерированный скрипт в тестовой базе, проверять, что он отрабатывает без ошибок.
Unit‑тесты для ETL‑процессов. Если у нас есть спецификация и DDL, то мы можем автоматически генерировать тесты для загрузки данных.
Передача артефактов между агентами. Сейчас скиллы уже умеют передавать контекст. Мы хотим развить это: чтобы агенты могли сами решать, кому передать промежуточные результаты, и автоматически запускать следующий этап.
Мониторинг качества. Мы планируем сделать дашборд с метриками по скиллам: сколько времени заняла генерация, сколько задач обработано, процент ошибок. Чтобы видеть, где скиллы работают хорошо, а где нужно дорабатывать.
Обучение на ошибках. Мы собираем фидбек от команды и используем его для дообучения агентов (fine‑tuning на основе конкретных примеров).
Подведем итоги
ИИ‑автоматизация — это усиление аналитика, а не замена. Мы не убираем людей. Мы убираем рутину. Аналитик тратит время на анализ, а не на оформление документов. ИИ забирает до 80% шаблонной работы.
Скиллы работают как конвейер. Это не разрозненные инструменты, а связанная цепочка. Каждый этап передает контекст следующему. Epic в Jira превращается в бизнес‑требования, те — в физическую модель, та — в DDL и маппинг. Все автоматически, без ручного перекладывания данных.
MCP‑сервер — полезный компонент. Он обеспечивает интеграцию с корпоративными системами без внешних зависимостей. Запускается локально и дает агенту доступ к Jira, Confluence, GitLab и другим источникам. И если ваши требования к безопасности позволяют — можно добавить и внешние источники, и базы данных, и что угодно.
Качество измеряемо. Мы не внедряем ИИ вслепую. У нас есть четкие метрики для каждого скилла, эталонные примеры и система аудита. Мы видим, где скиллы работают хорошо, а где их нужно дорабатывать.
Есть задачи, которые ИИ не заменит. Переговоры с заказчиками, интерпретация неоднозначных требований, архитектурные решения с долгосрочными последствиями, приоритизация в условиях ограниченных ресурсов — здесь нужен аналитик.
Мы тестируем скиллы на своих проектах. Пока не все работает идеально — многое зависит от качества входных данных, от того, как сформулировано ТЗ. Но там, где оно составлено хорошо, результат впечатляет.
Грамотно прописанный ИИ‑агент с настроенными скиллами — это большая помощь для дата‑аналитика. Он экономит время, страхует от ряда ошибок, делает команду более эффективной. Но он не решает абсолютно все задачи аналитика. Креативность, переговоры, понимание контекста — все это остается.
А вы пробовали внедрять подобные скиллы в своей работе? Или у вас есть определенные сомнения? Пишите, буду ждать истории и вопросы в комментариях.
