Сколько нужно знать о бизнесе до выбора ИИ-решения
Нужно ли описывать всю компанию перед ИИ-проектом? Разберите одну операцию, её стыки и цену ошибки. Карта вводных покажет, что выяснить до выбора решения.
Если на встрече показывают готового агента, а руководитель ещё не может сказать, кто проверит его ответ и что произойдёт с нестандартной заявкой, выбирать продукт рано. При этом описывать всю компанию тоже не требуется. Для первого решения достаточно разобраться в одной операции, её связях с соседними операциями, цене ошибки и невыясненных обстоятельствах, которые способны изменить выбор. Чем больше у решения прав, исключений и последствий ошибки, тем глубже придётся исследовать именно эти места.
Это не норматив по числу интервью или документов. Это способ понять, можно ли уже сравнивать типовой продукт, его настройку и отдельную разработку. Методика discovery GOV.UK предлагает сначала разобраться с проблемой, пользователями и ограничениями и допускает вывод «пока не строить сервис». Она создана для государственных сервисов; ниже — редакционная адаптация для небольшого бизнес-процесса.
Проведите границу вокруг решения, которое принимаете сейчас
Начните с действия, а не с организационной схемы. Например: «подготовить черновик карточки входящего обращения для менеджера». Где операция начинается: письмо попало в общий ящик. Где заканчивается: менеджер получил карточку и решил, кому отвечать. Продажи, доставка и бухгалтерия важны здесь лишь там, где они передают данные в эту операцию или получают её результат.
Запишите четыре слоя контекста.
- Цель и результат. Что сегодня делает человек, какой результат нужен и по чему его признают пригодным? «Ускорить работу» недостаточно: понадобится наблюдаемый критерий, например полнота полей карточки и отсутствие выдуманных сроков.
- Стыки. Кто отправляет вход, кто читает выход, кто исправляет ошибку? Какие системы нужны для чтения и записи? GOV.UK советует смотреть на путь пользователя и команды вокруг сервиса; для бизнеса это помогает заметить передачу, где результат может потеряться.
- Исключения и ограничения. Что делать с дубликатом, пустым письмом, жалобой, недоступной системой? Какие данные нельзя передавать выбранному инструменту? Кто вправе разрешить запись или отправку? Ответы особенно важны, если ошибка доходит до клиента без проверки.
- Отложенное. Детали соседнего отдела, которые не меняют ближайшее решение, помечайте как «проверить позже». Не заполняйте их догадкой ради полной схемы.
Соразмерьте исследование с вариантом решения
Эта развилка — рабочая редакционная схема, а не свойство всех ИИ-продуктов.
| Возможный путь | Чего нужно знать до выбора | Когда пока нельзя обещать результат |
|---|---|---|
| Правило, форма или существующий сервис без ИИ | Явные условия операции, объём ручных исключений, нужный выход | Если задержка связана не с инструментом, а со спором о том, кто отвечает за заявку |
| Типовой ИИ-продукт | Совпадают ли вход, выход, права, типовые случаи и путь проверки с доступными возможностями продукта | Если демонстрация была на удобном примере, а реальные исключения и доступы неизвестны |
| Настройка типового продукта | Какие конкретно поля, источники или правила не покрыты базовым сценарием; кто их поддерживает | Если «настройка» фактически требует нового рабочего процесса или неподтверждённой интеграции |
| Индивидуальная разработка | Поведение на стыках, источники данных, права, отказ и восстановление, критерии приёмки, будущий владелец изменений | Если ни один сотрудник не может подтвердить ожидаемый результат и спорные случаи |
Порог достаточности простой: команда может объяснить, почему выбранный путь подходит для обозначенной границы, назвать проверяемые допущения и остановить работу на случае, который ещё не согласован. Если неизвестное может перевернуть выбор пути, сначала выясните его. Если неизвестное влияет только на позднюю настройку и ограниченный пробный сценарий остаётся безопасным, его можно проверить на пробе. Microsoft предлагает описывать поток через бизнес-цель, участников и этапы; это полезный способ рассуждать, а не требование применять Azure.
Карта достаточных вводных: заполненный учебный пример
Это вымышленная операция, не клиентский кейс. Компания получает письма о заказах; обсуждается подготовка карточки для менеджера без автоматического ответа клиенту.
| Поле карты | Запись для учебного примера |
|---|---|
| Решение сейчас | Можно ли пробовать типовой инструмент, который готовит черновик карточки, или нужна разработка? |
| Граница процесса | Вход: письмо в общий ящик. Выход: черновик карточки на проверку менеджеру. Отправка ответа вне границы. |
| Ожидаемый результат | Указаны тема обращения и явно названные в письме товар и срок; неизвестное оставлено пустым, исходное письмо доступно для проверки. |
| Обычные и исключительные случаи | Обычный: один заказ в письме. Исключения: два заказа, вложение без текста, жалоба вместо заказа. По жалобе нужна передача человеку. |
| Данные и доступы | Для пробы — разрешённые обезличенные письма; возможность читать реальный ящик и записывать в CRM ещё не согласована. |
| Владелец решения | Руководитель продаж утверждает пригодность карточки; менеджер показывает рабочие случаи; ответственный за данные согласует допустимый вход. |
| Критерий проверки | На согласованных примерах менеджер сравнивает карточку с исходным письмом и отмечает пропуски, выдуманные значения и ошибочную маршрутизацию. Числовой порог приёмки ещё не назначен. |
| Неизвестное и следующий сбор | Проверить, есть ли у типового инструмента нужные поля и допустимый режим работы с данными; получить разрешённые примеры исключений и проверить возможность записи в CRM. |
Из этой карты следует ограниченное решение: можно сравнить типовые инструменты на черновике без отправки, но нельзя обещать запись в CRM, обработку жалоб или экономию времени. Если инструмент не сохраняет связь с исходным письмом либо подставляет придуманный срок, этот вариант не подходит даже для обозначенного сценария. Если выяснится, что основная задержка возникает из-за отсутствия ответственного менеджера, сперва измените маршрут заявки. Технология не решит за команду, кто отвечает за заявку.
Скопируйте пустую форму для своей операции:
| Поле | Ваша запись и источник подтверждения |
|---|---|
| Какое решение принимаем сейчас? | |
| Где начинается и заканчивается одна операция? | |
| Как выглядит пригодный результат? | |
| Какие обычные и исключительные случаи надо учесть? | |
| Откуда данные, какие доступы разрешены? | |
| Кто утверждает результат и разбирает ошибку? | |
| На чём и по какому признаку проверим? | |
| Что неизвестно, кто и как это выяснит? |
Разделите подтверждение и проверку
Заказчик может назвать бизнес-цель, показать действующий порядок и назначить человека, который вправе подтвердить результат и разрешить доступ к данным. Исполнитель должен прояснить противоречия, показать пределы предлагаемого продукта и проверить технические допущения, прежде чем обещать их выполнить. Решение о пробе и её границах стоит записать вместе. Это практическое распределение работы, не универсальное условие договора; конкретные обязанности стороны согласуют отдельно. В рекомендациях Microsoft по развёртыванию также подчёркнута важность явных владельцев решений, но предложенная там форма распределения ролей не обязательна для каждого проекта.
Карту пересматривают, когда меняется граница операции, добавляется право отправлять или изменять данные либо обнаруживается новое исключение с высокой ценой ошибки. Если по ключевой строке стоит только предположение, ближайшее действие — получить пример у того, кто делает эту работу, и подтвердить вывод у владельца процесса. Когда операция и ограничения понятны, можно перейти к сравнению цифровых сотрудников под конкретный процесс.
Комментарии
Обсуждение этой статьи пока закрыто.