AI Discovery — это короткий проектный этап, на котором бизнес проверяет, стоит ли внедрять ИИ в конкретный процесс и как именно измерить результат. Команда описывает текущий маршрут, замеряет потери, изучает данные и интеграции, выделяет безопасную границу пилота, выбирает KPI и фиксирует риски. На выходе нужны не общие идеи, а артефакты: карта «как есть», целевой сценарий, перечень данных, архитектурная схема, критерии приёмки, оценка сроков и бюджета. Discovery может закончиться решением не разрабатывать систему: использовать готовый сервис, сначала исправить процесс или остановить гипотезу. Это нормальная ценность этапа — снизить цену ошибки до крупных инвестиций.
Оглавление
- Кому нужен Discovery
- Какие вопросы он закрывает
- Экономика этапа
- Как проходит работа
- Что должно быть на выходе
- Готовый сервис или разработка
- Ошибки
- Чек-лист
- FAQ
Кому нужен Discovery
Этап нужен, когда есть заметная бизнес-проблема, но ещё нет доказанной границы решения. Например, отдел долго обрабатывает спецификации, менеджеры пропускают обращения, закупки сравнивают несовместимые таблицы, а руководство собирает отчёт вручную. Формулировка достаточно конкретна для исследования, но недостаточна для сметы и приёмки.
Discovery особенно полезен в четырёх ситуациях:
- несколько подразделений по-разному описывают один процесс;
- данные распределены между почтой, Excel, CRM, 1С и документами;
- поставщики предлагают несопоставимые способы решения;
- ошибка автоматического действия имеет финансовое или репутационное последствие.
Если задача полностью типовая, данные уже структурированы, а готовый сервис соответствует требованиям, полноценный этап можно сократить до проверки совместимости и ограниченного теста. Но пропуск вопросов о KPI, данных и правах всё равно создаёт риск.
Какие вопросы закрывает Discovery
Что именно теряет бизнес? Часы, скорость, качество, контроль, выручку или управляемость. Потеря привязывается к событию и источнику данных.
Где проходит граница процесса? Какое событие запускает работу, кто участвует, какой результат завершает цикл, где находятся ожидания и возвраты.
Какая часть подходит ИИ? Извлечение, классификация, поиск, сопоставление, подготовка черновика, контроль отклонений. Решение и ответственность остаются у назначенной роли.
Какие данные доступны? Форматы, объём, качество, права, персональные и чувствительные поля, эталоны, срок хранения.
Куда должен попасть результат? В карточку CRM, документ, задачу, очередь проверки или управленческий отчёт. Без точки записи прототип остаётся отдельным инструментом.
Как будет принята работа? Метрика качества, время цикла, доля применимости, объём теста, список критичных ошибок и правило ручной обработки.
Экономика Discovery
Ценность этапа — не в гарантированной экономии, а в уменьшении неопределённости. Можно сравнить стоимость Discovery с ожидаемой ценой ошибочного пути: разработкой ненужных функций, интеграцией до проверки качества данных, покупкой неподходящих лицензий или запуском без владельца.
Пример управленческой модели, где все числа условны:
| Вариант | Модельные затраты до решения | Что узнаёт бизнес | Основной риск | |---|---:|---|---| | Сразу купить подписку | 300 000 ₽ | качество типовой функции | ручной процесс вокруг сервиса | | Сразу начать разработку | 1 500 000 ₽ | результат после значительной инвестиции | неверная граница и переделка | | Провести Discovery | 250 000 ₽ | процесс, данные, KPI, архитектура, оценка | требуется участие экспертов |
Таблица не доказывает, что Discovery всегда дешевле или обязателен. Она показывает способ сравнения: стоимость знания до обязательства. Подставьте собственные цены, сроки и вероятность переделки. Если готовый продукт можно безопасно проверить за день, длинное исследование не нужно. Если затронуты несколько систем и критичные решения, цена неопределённости выше.
Как проходит работа
1. Установочная рамка
Заказчик называет бизнес-владельца, проблему, желаемый результат и ограничения. Команда фиксирует, что не исследуется. Это защищает этап от превращения в аудит всей компании.
2. Интервью и наблюдение
Разговора с руководителем недостаточно. Нужно увидеть работу исполнителя: какие файлы приходят, где он ищет данные, что перепроверяет, кому передаёт исключение. Различия между регламентом и реальностью документируются без поиска виноватых.
3. Карта процесса и базовая линия
Для каждого шага отмечаются вход, действие, система, роль, ожидание, ошибка и выход. Затем измеряются объём, активное время, полный цикл, возвраты и стоимость. Если системной статистики нет, задаётся временный замер.
4. Аудит данных
Команда получает ограниченную репрезентативную выборку, проверяет форматы, дубли, пропуски, качество сканов, соответствие справочников и наличие эталонного ответа. Одновременно определяются правовые основания и доступы; лишние данные исключаются.
5. Проектирование сценария
Выбирается точка, где система помогает: распознаёт, классифицирует, сопоставляет или готовит черновик. Описываются человеческое подтверждение, исключения, запись результата и ручной резервный путь.
6. Техническая проверка
Исследуются API, способы обмена, авторизация, ограничения производительности, размещение и журналирование. Иногда короткий технический эксперимент нужен, чтобы проверить качество на реальных форматах.
7. Экономика и приёмка
Считается текущая стоимость, модельный эффект и TCO. KPI связываются с источниками. Фиксируются минимальный объём пилота, допустимые ошибки и критерии остановки.
Текстовая схема этапа:
Бизнес-потеря
↓
процесс «как есть» + базовые KPI
↓
данные ── ограничения ── интеграции
↓
целевой маршрут с контролем человека
↓
граница пилота + приёмка + экономика
↓
решение: готовый сервис / пилот / подготовка / стоп
Что должно быть на выходе
Качественный Discovery завершается комплектом, который можно проверить и передать другой команде.
- Одностраничное резюме. Проблема, гипотеза, экономика, риски и рекомендуемое решение.
- Карта текущего процесса. События, роли, системы, ожидания и исключения.
- Целевой маршрут. Где работает система, где принимает решение человек, куда записывается результат.
- Паспорт данных. Источники, форматы, объёмы, качество, доступы и ограничения.
- Базовая линия. Значения KPI, способ и дата измерения.
- Архитектурная схема. Компоненты, обмен, роли, логирование и ручной режим.
- Backlog пилота. Обязательные сценарии и явно отложенные функции.
- План приёмки. Выборка, метрики, критичные ошибки, тестовые роли.
- Оценка. Этапы, зависимости, диапазон бюджета и регулярные расходы.
- Реестр рисков. Вероятность, последствия, меры и владелец.
Если результат состоит только из презентации с вариантами применения ИИ, это исследование идей, а не достаточная подготовка внедрения.
Как Discovery выбирает способ решения
Готовый сервис выбирают, когда процесс типовой, данные и права совместимы, интеграция не критична, а тест подтверждает качество. Discovery должен проверить стоимость полного маршрута, включая ручной перенос и ограничения тарифа.
Интеграционный вариант подходит, когда типовая AI-функция должна работать внутри существующих систем и корпоративных правил. Используются готовые модели, но процесс, интерфейс подтверждения и обмен проектируются под компанию.
Собственная разработка оправдана уникальной логикой, объёмом, требованиями контроля или отсутствием готового решения. Этап должен объяснить, какая уникальность действительно создаёт ценность, а не просто повторяет существующий продукт.
Иногда рекомендация — сначала очистить справочник, изменить регламент или настроить обычную автоматизацию без ИИ. Это не провал: более простой способ с тем же эффектом предпочтительнее.
Ошибки Discovery
Исследовать всю компанию. Граница расползается, решения остаются поверхностными. Нужен один дорогой процесс.
Верить только регламенту. Реальные исключения и ручные обходы обнаруживаются поздно. Нужны наблюдение и выборка.
Сделать демо вместо измерения. Красивый ответ на трёх документах не показывает применимость и полный цикл.
Не включить безопасность. После успешного теста выясняется, что данные нельзя передавать или нет нужного журнала.
Не назначить владельца KPI. Показатель выбран, но никто не отвечает за выгрузку и интерпретацию.
Обещать результат пилота заранее. Discovery уменьшает неопределённость, но не гарантирует точность, принятие или ROI.
Связать этап с единственным решением. Исследование должно честно допускать готовый сервис, паузу или отказ.
Чек-лист готовности
- [ ] Назван один процесс и его бизнес-владелец.
- [ ] Понятны начало и конец операции.
- [ ] Доступны исполнители для интервью и наблюдения.
- [ ] Есть репрезентативная выборка входов.
- [ ] Известны системы чтения и записи.
- [ ] Можно получить базовый объём и время.
- [ ] Перечислены чувствительные данные и ограничения.
- [ ] Определены роли ИТ и безопасности.
- [ ] Согласован формат результатов этапа.
- [ ] Допускается решение «не внедрять ИИ».
- [ ] Зафиксирован список вне границы.
- [ ] Назначена встреча принятия решения.
Связанные материалы
Практический формат этапа описан на странице AI Discovery. До старта полезно прочитать, как выбрать первый процесс и подготовить данные для пилота.
FAQ
Полезный побочный эффект Discovery — общий язык между владельцем процесса, пользователями, безопасностью и разработкой. Команда заранее договаривается, что считается входом, исключением и результатом, поэтому спор о качестве опирается на примеры и измерения, а не на впечатление от демонстрации.
AI Discovery — это платная консультация?
Это проектный этап, ценность которого проверяется артефактами. Карта процесса, базовая линия, паспорт данных, целевая архитектура и приёмка должны позволить бизнесу принять решение и при необходимости продолжить с другой командой.
Нужно ли заранее готовить идеальные данные?
Нет. Нужны доступ к выборке, понимание права использования и эксперт, способный объяснить правильный результат. Оценка качества и план подготовки являются частью работы. Полное очищение всех архивов до исследования часто избыточно.
Кто должен участвовать?
Бизнес-владелец, один–два реальных пользователя, представитель ИТ и при необходимости безопасность или юристы. Состав зависит от данных и интеграций. Важно, чтобы решения принимали конкретные роли, а не неопределённый комитет.
Обязательно ли после Discovery запускать разработку?
Нет. Возможны готовый сервис, обычная автоматизация, подготовительный проект, пилот или остановка. Качественный этап уменьшает вероятность инвестировать в неправильный путь.
Следующий шаг
Сформулируйте процесс по схеме «вход → ручное действие → выход», назовите потерю и системы. Затем запросите AI Discovery, чтобы получить измеримую границу решения до разработки.