План собственника на 90 дней

Первые девяносто дней нужны, чтобы принять обоснованное решение о конкретном процессе. Они не гарантируют завершения сложной интеграции и не являются обязательным сроком окупаемости. Если исходные данные недоступны или согласование требует больше времени, план должен это отражать.

К этому моменту у вас есть паспорт процесса, расчёт экономики, реестр источников, схема ролей и критерии пилота. Соедините их в управленческую программу. Не начинайте заново с выбора красивого названия агента: теперь понятно, какую работу он должен выполнить и как компания проверит результат.

Дни 1–15: договориться о задаче

Выберите процесс, владельца и границу первого результата. Соберите примеры работы и исходные показатели. Проверьте доступность источников и участие принимающего сотрудника. Запишите, что в проект не входит.

Результатом этапа становится решение о допустимости пилота. Если данных недостаточно, полезная работа — организовать их получение. Не ускоряйте график, подменяя реальные примеры демонстрационными и выдавая их за рабочий поток.

Дни 16–30: подготовить проверку

Сформируйте набор обычных и проблемных случаев, правила приёмки и ограничения прав. Подготовьте базовый экономический сценарий с учётом проверки. Согласуйте, кто и сколько времени выделяет.

К концу этапа должна существовать возможность повторить проверку. Устная договорённость «посмотрим, понравится ли» не позволяет отличить улучшение от адаптации ожиданий. При необходимости сократите объём до одного типа обращения или документа.

Модель 12 · дорожная карта

Развернуть ↗Поделиться ↗

EVOLVIN MEDIA / ПРАКТИКА

Каждый этап 90 дней заканчивается управленческим решением

1. 01

   1–15 дней

   Задача и исходная точка

2. 02

   16–30 дней

   Набор примеров и критерии

3. 03

   31–60 дней

   Ограниченный пилот

4. 04

   61–90 дней

   Решение и план эксплуатации

90 дней — маршрут решений, а не обещание результата.

Переслать мысль с карточкой ↗

Как читать схему

Предлагаемый шаблон EVOLVIN. На переходе между этапами подтверждайте готовность; при провале условий вернитесь к подготовке или остановите проект.

Вертикальная версия для телефона. Полную композицию можно открыть кнопкой «Развернуть».

Дни 31–60: испытать и разобрать

Запускайте ограниченно, фиксируйте версии и анализируйте исключения. Разделяйте настройку и итоговую оценку. Привлекайте реальных будущих пользователей, а не только участников демонстрации.

Каждую неделю принимайте одно из решений: продолжать по плану, менять конкретное условие или остановить участок. Не накапливайте новые функции, пока прежний результат не принят. Даже успешный пилот может показать, что следующий шаг — изменить входную форму, а не покупать дополнительного агента.

Дни 61–90: определить режим эксплуатации

Пересчитайте экономику по наблюдениям. Опишите оставшиеся ограничения, поддержку, версии и порядок остановки. Согласуйте контрольные показатели после запуска. Если продолжение оправдано, расширьте только одну границу.

Для команды «Контур-Сервиса» это может означать увеличение объёма брифов при прежнем режиме проверки. Автоматическая отправка писем остаётся отдельным проектным решением. Успех на подготовительном этапе не превращается в право автономно обещать условия.

Итоговая записка на одну страницу

Собственнику нужна записка: какую работу меняли, что наблюдали, сколько стоило получение принятого результата, какие риски остались и что предлагается дальше. Рядом сохраняются подробные материалы, но решение должно быть читаемым без их пересказа.

Выберите один вывод: не внедрять, доработать, эксплуатировать ограниченно или расширять. Отказ от невыгодного сценария — нормальный управленческий результат. Цель — не доказать любовь к ИИ, а улучшить работу компании на понятных основаниях.

Как не превратить план в календарь пожеланий

У каждого этапа должно быть решение, которое можно принять. Если к пятнадцатому дню нет доступных данных, дата следующей встречи не означает автоматического начала настройки. Пересмотрите содержание этапа и назначьте ответственного за препятствие.

Раз в неделю сопоставляйте ожидаемый результат с фактическим. Записывайте, какое допущение изменилось: поток, трудоёмкость, доступность источника или время проверки. План остаётся полезным, когда отражает эти изменения, а не сохраняет первоначальную картинку ради отчётности.

Перед итоговым решением попросите человека, не участвовавшего в настройке, прочитать записку и объяснить вывод. Если он не понимает, что проверено и почему предлагается продолжение, добавьте основания. Управляемый проект заканчивается объяснимым решением, а не только демонстрацией работоспособного интерфейса.