Первые 30 дней

Иллюстрация. Первые 30 дней: один контур, четыре недели, видимый результат.

Самая частая ошибка после вдохновляющей встречи про ИИ — попытаться сразу “внедрить во всей компании”. Руководитель видит возможности, команда приносит десятки идей, сотрудники уже используют разные модели, технический руководитель говорит про MCP-шлюз, безопасность, интеграции, память, права,

open-source модели и закрытый контур. В какой-то момент все становится слишком большим.

Появляется ощущение, что нужно сначала построить платформу, описать все процессы, подключить все системы, обучить всех

сотрудников, договориться со службой безопасности, выбрать модель, написать регламенты, собрать базу знаний, оформить сотни skills. Так внедрение застревает. AI-Native переход не нужно начинать со всей компании. Его нужно начинать с первого управляемого контура.

Не демонстрации. Не чата. Не раздачи подписок.

А именно контура, где есть:

роль;

повторяющаяся работа;

ассистент;

один или несколько skills;

source of truth;

правила качества;

права;

метрики;

владелец результата;

понятный эффект.

Первые 30 дней нужны не для того, чтобы “закончить внедрение”.

Они нужны, чтобы доказать: компания способна превратить ИИ в управляемую работу.

Цель первых 30 дней

Цель первого месяца — не максимальная автоматизация. Цель — собрать минимальное операционное ядро, которое можно показать, измерить и повторить.

Хороший результат первых 30 дней выглядит так:

выбран один рабочий контур;

описана усиленная роль;

подготовлены 2-4 рабочих skills;

определены source of truth;

подключены или хотя бы описаны нужные источники данных;

задана модель прав;

описаны правила качества;

собран исходный замер;

проведены реальные рабочие задачи;

получена обратная связь от пользователей;

показан эффект руководителю;

принято решение о следующей волне.

Плохой результат выглядит иначе:

купили доступ к модели;

провели обучение по промптам;

сотрудники поигрались;

несколько человек стали пользоваться активнее;

один энтузиаст показал красивый пример;

руководитель не понял, что изменилось в бизнесе;

через месяц все вернулось к старому режиму.

Разница между этими двумя результатами — в управлении.

Выберите не “самый интересный”, а правильный первый контур

Первый контур не должен быть самым модным. Он должен быть

подходящим для доказательства эффекта. Хороший первый контур имеет несколько признаков.

Работа повторяется

Если задача случается один раз в год, ее трудно использовать для

пилота.

Лучше брать то, что происходит регулярно:

обработка входящих заявок;

подготовка коммерческих предложений;

проектные статусы;

протоколы встреч;

проверка договоров;

постановка задач;

подготовка release notes;

первичная аналитика клиента;

ответы поддержки;

сбор документов для сделки.

Повторяемость важна, потому что без нее нельзя измерить улучшение.

Есть боль

Если процесс и так работает хорошо, эффект будет трудно

показать.

Ищите место, где люди уже жалуются:

долго;

много ручной работы;

часто возвращается на доработку;

теряется контекст;

зависит от одного сильного сотрудника;

документы готовятся каждый раз заново;

статус собирается вручную;

входящие запросы лежат без движения;

качество сильно отличается от человека к человеку.

ИИ хорошо заходит туда, где рутина уже раздражает людей.

Есть владелец

Без владельца первый контур расползется. Нужен человек, который отвечает за результат процесса и готов менять работу. Это

может быть руководитель продаж, PM Lead, технический руководитель, операционный директор, руководитель поддержки, финансовый контролер, владелец документооборота.

Важно, чтобы он мог сказать:

Да, это мой процесс. Я готов проверить новый способ работы и отвечать за внедрение.

Данные доступны

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

Лучше выбрать контур, где source of truth уже хотя бы частично понятен:

задачи в трекере;

клиенты в CRM;

документы в базе знаний;

шаблоны в корпоративном хранилище;

код в Git-репозитории;

договоры в документообороте;

встречи в календаре.

Не обязательно, чтобы все было идеально. Но должно быть понятно, откуда ассистент берет факты.

Есть безопасный режим старта

Для первого месяца лучше выбирать сценарии, где ассистент может начать с Delegate и Review, а не сразу с широкого Act.

Например:

подготовить черновик КП, но не отправлять клиенту;

проверить договор, но не согласовывать его;

собрать статус, но не менять сроки;

подготовить задачу, но не назначать людей без подтверждения;

создать запрос на изменение кода, но не сливать его в основную

ветку.

Так компания получает эффект без лишнего риска.

Матрица выбора первой волны

Чтобы не выбирать на вкус, можно использовать простую матрицу.

Оцените каждый кандидатный сценарий по пяти критериям от 1 до 5:

Повторяемость

Боль Доступность данных Безопасность старта

Измеримость эффекта

Сценарий с высоким суммарным баллом подходит для первой волны.

Но есть еще один важный фильтр:

Есть ли человек, который будет владельцем этого контура?

Если владельца нет, сценарий лучше отложить. Даже если он красивый.

Как первые контуры выглядят в разных индустриях

Один и тот же принцип может выглядеть по-разному. В сервисной ИТ-компании первым контуром часто становится подготовка коммерческого предложения, проектный статус или инженерная задача. Там легко увидеть время, качество, возвраты и влияние на

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

В нефтетрейдинге или сырьевом бизнесе первым контуром может

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

В дистрибуции первым контуром может стать работа с входящим спросом: сопоставить запрос клиента с каталогом, проверить остатки или ограничения, подготовить варианты ответа и зафиксировать следующий шаг в CRM. В каждом примере ассистент не “внедряется в компанию вообще”. Он входит в конкретную повторяющуюся работу, где есть владелец, source of

truth, правила качества и измеримый эффект.

Что не брать в первый месяц

Есть сценарии, которые выглядят заманчиво, но плохо подходят для старта.

Слишком стратегические задачи

Например: “пусть ИИ разработает стратегию компании”. Ассистент может помочь в анализе, но это плохой первый контур.

Слишком много неопределенности, слишком трудно измерить эффект, слишком высок риск разочарования.

Слишком чувствительные данные

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

Слишком много систем сразу

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

Сценарии без владельца

“Было бы полезно всем” — плохой признак. Если полезно всем, обычно не отвечает никто. Для первого месяца нужен конкретный владелец.

Неделя 1. Выбор контура и исходный замер

Первая неделя — не про технологию. Она про фокус. Нужно

выбрать один контур и описать, как он работает сейчас.

Минимальные действия:

Провести короткое интервью с владельцем процесса.
Описать текущий путь работы.
Найти 3-5 повторяющихся задач.
Определить source of truth.
Зафиксировать боли.
Сделать исходный замер.
Выбрать пользователей первой группы.

Исходный замер не должен быть сложным.

Например, для коммерческого предложения:

сколько времени занимает подготовка;

сколько раз документ возвращается на доработку;

какие блоки каждый раз пишутся вручную;

где берутся данные;

какие ошибки повторяются;

какой процент предложений уходит в срок.

Для проектного статуса:

сколько времени PM тратит на сбор;

сколько задач без актуального статуса;

сколько блокеров всплывает поздно;

сколько встреч уходит на выяснение фактов;

сколько ручных сообщений нужно отправить.

Для инженерной задачи:

сколько времени уходит на вход в контекст;

сколько возвратов с ревью;

какие ошибки повторяются;

сколько времени занимает описание MR;

какие проверки забываются.

Без исходного замера компания не сможет доказать эффект. Будет

ощущение. А руководителю нужен факт.

Неделя 2. Роль, skills и source of truth

На второй неделе нужно превратить выбранный контур в рабочую модель.

Описать усиленную роль

Не “у нас будет ассистент для отдела”.

А конкретно:

Роль: менеджер по продажам Контур: подготовка коммерческого предложения

Цель: сократить время подготовки и повысить качество входных данных Ассистент помогает: собрать контекст, найти похожие материалы, подготовить

структуру, проверить полноту, сформировать черновик Человек отвечает: за позиционирование, обещания клиенту, финальную редакцию

и отправку

Для PM:

Роль: руководитель проекта

Контур: еженедельный статус Ассистент помогает: собрать задачи, выделить блокеры, проверить просрочки, подготовить summary, найти открытые решения

Человек отвечает: за приоритеты, коммуникацию с клиентом, управленческие решения и эскалации

Создать первые skills

Не нужно сразу описывать десятки skills. Для первой волны достаточно 2-4.

Например, для продаж:

client-context-summary;

proposal-draft;

proposal-quality-review;

next-step-email-draft.

Для проектного управления:

project-status-summary;

blockers-review;

meeting-prep;

decision-log-update.

Для инженерного контура:

task-context-bootstrap;

implementation-plan;

mr-description;

review-checklist.

Каждый skill должен быть коротким, но конкретным:

цель;

входы;

source of truth;

шаги;

ограничения;

правила качества;

где остановиться;

формат результата.

Закрепить source of truth

У каждого skill должен быть ответ на вопрос:

Где ассистент берет правду?

Не “из интернета”. Не “из чата”. Не “из того, что пользователь вспомнил”.

А из конкретных источников:

CRM;

трекер;

база знаний;

файл шаблона;

документ договора;

календарь;

Git-репозиторий;

утвержденная методика;

карточка клиента;

протокол встречи.

Если source of truth нет, это тоже результат. Значит, первый контур покажет не только пользу ИИ, но и дыру в управлении знаниями.

Неделя 3. Безопасный запуск на реальных задачах

На третьей неделе ассистент должен выйти из режима “мы

обсуждаем” в режим “мы делаем”. Но запуск должен быть безопасным. Лучше начать с 3-7 реальных задач.

Например:

подготовить три коммерческих предложения;

собрать пять проектных статусов;

проверить десять задач на полноту;

подготовить протоколы по нескольким встречам;

сделать несколько MR с помощью агента разработки;

проверить пакет документов по нескольким сделкам.

Важно: это должны быть реальные рабочие задачи, а не учебные примеры. Иначе команда не почувствует ценности.

На этой неделе нужно фиксировать:

сколько времени заняло выполнение;

где ассистент помог;

где ошибся;

какие данные не нашел;

какие instructions были непонятны;

какие части skill нужно поправить;

где человек все равно делал вручную;

какой результат можно использовать.

После первых запусков skills почти всегда нужно переписать. Это нормально. Skill рождается не из красивого текста, а из

столкновения с реальной работой.

Неделя 4. Измерение, разбор и решение о следующей волне

Четвертая неделя нужна для управленческого вывода. Не для празднования. И не для поиска виноватых.

Нужно ответить на три вопроса:

Что улучшилось?
Что не сработало?
Что делаем дальше?

Минимальный отчет по пилоту должен включать:

описание контура;

пользователей;

список skills;

source of truth;

исходный замер;

фактический результат;

примеры артефактов;

ошибки ассистента;

риски;

предложения по улучшению;

решение о следующей волне.

Например:

Контур: подготовка коммерческого предложения Период: 4 недели Пользователи: 3 менеджера

Задачи: 12 КП

Было: - среднее время подготовки: 4 часа

возвраты на доработку: 60% - часто забывались ограничения ИБ и похожие кейсы

Стало:

среднее время подготовки: 1 час 40 минут - возвраты на доработку: 25% - появился единый quality review
выявлен недостаток: нет актуального реестра шаблонов

Решение: - расширить на всю группу продаж;

оформить 2 новых skills; - закрепить владельца шаблонов;
подключить CRM через MCP-шлюз на следующей волне.

Такой отчет понятен руководителю. Он показывает не “мы использовали ИИ”, а изменение работы.

Что должно быть готово к первому пилоту

Перед запуском реальных задач проверьте минимум.

Управленческий минимум

выбран один контур;

назначен владелец;

определены пользователи;

описана роль;

понятен ожидаемый эффект;

есть исходный замер;

есть дата разбора результатов.

Методический минимум

описаны 2-4 skills;

у каждого skill есть цель и результат;

описаны source of truth;

есть правила качества;

есть правило остановки;

понятно, что делает человек.

Технический минимум

выбран инструмент доступа к ассистенту;

настроены базовые права;

понятно, какие данные можно использовать;

чувствительные данные не уходят без правил;

есть место, куда сохраняется результат;

есть способ собрать обратную связь.

Организационный минимум

пользователи понимают, что это рабочий эксперимент;

руководитель готов смотреть на метрики;

ошибки ассистента не скрываются;

улучшения skills фиксируются;

есть короткий ритм разбора: хотя бы раз в неделю.

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

Как выбрать первую группу пользователей

Не начинайте со всей компании. Первая группа должна быть маленькой, но настоящей. Хороший размер — 3-7 человек.

В группе должны быть:

владелец процесса;

2-4 активных пользователя;

человек, который хорошо знает текущий процесс;

технический или методический помощник;

руководитель, который будет смотреть на результат.

Не стоит брать только энтузиастов. Они покажут красивые примеры, но не покажут реальную сложность внедрения. Не стоит брать только скептиков. Они могут утопить пилот до того, как он заработает.

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

Как объяснить пилот команде

Люди должны понимать, что происходит.

Плохое объяснение:

Теперь у нас ИИ, он будет повышать эффективность.

Такое звучит угрожающе и пусто.

Лучше:

Мы берем один повторяющийся процесс и пробуем убрать

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

остаются за людьми. Через месяц мы посмотрим, стало ли

быстрее и лучше.

Еще лучше, если руководитель прямо скажет:

Наша цель — не поймать людей на ошибках, а собрать

новый способ работы. Ошибки ассистента и неудобства

процесса нужно фиксировать, потому что именно так мы

улучшаем skills.

Тон запуска сильно влияет на принятие. Если люди чувствуют угрозу, они будут защищаться. Если видят возможность убрать бессмысленную рутину и усилить свою роль, они включаются быстрее.

Почему 30 дней достаточно

За 30 дней нельзя построить зрелую AI-Native компанию. Но за 30

дней можно понять, есть ли управленческая способность двигаться в эту сторону.

Можно увидеть:

готовы ли руководители выбирать фокус;

есть ли владельцы процессов;

можно ли найти source of truth;

способны ли сотрудники работать с ассистентом;

получается ли оформлять skills;

виден ли эффект;

где главные ограничения;

что нужно строить дальше.

Если за 30 дней не произошло ничего, кроме разговоров, это тоже сигнал. Значит, проблема не в модели. Проблема в управлении переходом.

Типовые ошибки первого месяца

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

“Автоматизировать продажи” — слишком широко. “Подготовка черновика КП по входящему запросу” — уже рабочий контур. Третья ошибка — не сделать исходный замер. Без него руководитель не поймет, стало лучше или просто стало интереснее.

Четвертая ошибка — не назначить владельца. Ассистент без владельца процесса превращается в общую игрушку. Пятая ошибка — сразу требовать автономных действий. Для первого месяца чаще полезнее Delegate и Review, чем широкий Act.

Шестая ошибка — не обновлять skills после первых запусков. Первый текст skill почти всегда несовершенен. Его нужно улучшать по реальным ошибкам. Седьмая ошибка — считать сопротивление сотрудников глупостью.

Часто люди сопротивляются не ИИ, а неопределенности: что от них теперь ждут, как будет оцениваться работа, кто отвечает за ошибку, не станет ли ассистент способом контроля.

Что сделать руководителю

На этой неделе соберите короткую сессию на 90 минут.

Участники:

руководитель направления;

владелец процесса;

технический руководитель или архитектор;

2-3 человека из будущей пилотной группы;

человек, отвечающий за данные или безопасность, если контур

чувствительный.

Повестка:

Назвать 5-7 кандидатных сценариев.
Оценить их по матрице первой волны.
Выбрать один контур.
Назначить владельца.
Описать ожидаемый эффект.
Зафиксировать source of truth.
Назначить дату разбора через 30 дней.

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

Вопросы для руководителя

Какой один процесс вы готовы улучшить первым?

Где сейчас больше всего ручной рутины?

Где эффект можно увидеть за 4 недели?

Кто владелец этого процесса?

Какие 2-4 skills нужны для первого запуска?

Где лежит source of truth?

Что ассистенту можно делать без риска?

Что требует проверки человека?

Как вы измерите результат?

Кто примет решение о следующей волне?

Главная мысль главы

Первые 30 дней нужны не для того, чтобы внедрить ИИ “везде”. Они нужны, чтобы собрать первый доказуемый AI-Native контур. Выберите узкую повторяющуюся работу, назначьте владельца,

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

операционной системы.