# Директор и машина — Операционное управление: полные тексты (часть 1 из 2)

Направление: Операционное управление — процессы и регламенты · узкие места · рутина под нож
Хаб направления: https://davidgerstein.pro/operacii/
Материалов в файле: 10 из 17 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json
Другие части этого направления: https://davidgerstein.pro/llms-operacii-2.txt

## Нейросеть для работы с текстом: гайд по Claude — от чата до агентов и MCP
URL: https://davidgerstein.pro/operacii/claude-dlya-rukovoditelya/
Дата: 2026-08-29
Направление: Операционное управление
Цифры: 6 ступеней возможностей · 3 контура в проде · ~$300/мес за 100% звонков
Коротко: Нейросеть для работы с текстом — это не «напиши письмо», а исполнитель в процессе. Claude от Anthropic силён на длинных текстах, документах и данных: в компании на 40 человек он оценивает 100% звонков отдела продаж за ~$300 в месяц, разбирает документы 79 типов с точностью 85%, собирает протоколы планёрок. Возможности выстраиваются в шесть ступеней: тексты, документы, таблицы, изображения, подключение к вашим системам через MCP, агентный режим. Большинство застревает на первой — не из-за модели, а потому что не решились доверить машине процесс. Вход стоит вечер, а не проект.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш опыт с нейросетями закончился на «спросил — получил ерунду», вы попробовали не тот инструмент и не тем способом. Это как судить об автомобиле, посидев в нём на парковке. Я тоже начинал с ерунды на выходе. Месяц был уверен, что тема раздута: просишь письмо клиенту — получаешь вежливую пустоту, просишь разбор — получаешь пересказ очевидного. Потом дошло, что дело не в машине. Сегодня Claude у нас не помощник. Он работает: три производственных участка, круглосуточно, с понятной себестоимостью операции. Ниже — что это за инструмент, шесть ступеней его возможностей и на какой застряли лично вы. Нейросеть для работы с текстом: что это даёт руководителю Нейросеть для работы с текстом читает и пишет деловые документы: письма, договоры, расшифровки, протоколы, жалобы. В компании на 40 человек это не помощник в чате, а исполнитель на трёх производственных участках: оценивает 100% телефонных разговоров примерно за $300 в месяц , разбирает документы 79 типов с точностью 85% и собирает управленческую отчётность. Порог входа ниже, чем принято думать: пилот через интерфейс программиста стоит десятки долларов. Дорого обходится не модель, а время руководителя на приёмку в первые месяцы — и именно его надо планировать. Как нейросеть работает с текстом у нас в компании Обзоров «что умеет Клод» в интернете достаточно, поэтому начну не с описания, а с производственных участков: везде на входе текст, на выходе — управленческое решение или документ. Оценка звонков отдела продаж. Раньше контролёр успевала прослушать четверть потока — на большее не хватает рук ни у кого. Сейчас машина оценивает каждый разговор по чек-листу своего типа: 7 139 оценок, около $300 в месяц , охват вырос с 25% до 100%. Доверие настраивалось не верой, а калибровкой на 66 звонках с параллельной ручной оценкой и разбором каждого расхождения. Человек, полный рабочий день ~25% Контур на Claude 100% Разбор входящих документов. Поток 79 типов, которые раньше сортировали и переносили руками. Стартовая точность машины была удручающей — 59%. После работы с эталонной выборкой и правилами её довели до 85%, а полтора часа возни с комплектом сжались до минут . Оставшиеся 15% никуда не делись — их держит человек на приёмке, и это честная часть картины. Протоколы планёрок. Расшифровка совещания превращается в решения, задачи и ответственных. На отдел из 15 человек — порядка 70 часов экономии в месяц (оценка) . Не потому, что протокол долго писать, а потому, что без него половину решений переспрашивают заново. Общее у всех трёх: машина здесь не собеседник, а исполнитель в процессе — с регламентом, ценой операции и человеком, который принимает результат. Как считаются деньги на всё это — в разборе реальных расходов . Справка: что это за инструмент и сколько стоит Claude (по-русски — Клод) сделала американская компания Anthropic; официальный сайт — claude.ai, там же приложения для компьютера и телефона. Про доступ из России скажу честно и без инструкций: напрямую сервис в РФ не представлен, поэтому российский бизнес чаще работает через API — шлюзы и корпоративные контуры. Все наши участки устроены именно так. Специализация — работа с текстом: длинные документы, расшифровки, договоры. Договор на тридцать страниц или часовая расшифровка для него штатная задача. Есть «проекты» — папки с накопленным контекстом, чтобы не объяснять свою компанию заново в каждом чате. Русский язык полноценный, деловой тон держит. Форматов два, и путать их дорого. Чат — работаете вы: бесплатная версия для знакомства, платная — десятки долларов в месяц. API — работают ваши процессы без вас, оплата за объём. Вся автоматизация живёт во втором, и экономика там другая: не подписка, а себестоимость операции. Формат Кто работает Цена Для чего Чат бесплатный вы 0 ₽, лимит объёма знакомство, разовые задачи Чат по подписке вы десятки $/мес ежедневная работа руководителя API, контур машина, вы принимаете за объём: у нас ~$300/мес за 100% звонков регулярные процессы Ещё пара слов о характере инструмента, потому что это влияет на выбор. Anthropic делает ставку на предсказуемость: Claude реже уходит в фантазии на деловых текстах и лучше держится в рамках инструкции. Для развлекательных задач это скорее минус, для писем клиентам и договоров — ровно то, что нужно. И да, «чем отличается от ChatGPT» — вопрос, который задают первым. Отвечаю как практик: для деловых задач рабочие оба, разница между ними меньше, чем разница между внятной и невнятной постановкой задачи. Шесть ступеней. На какой застряли вы Смотрите, вот вся тема на одной лестнице. Каждая следующая ступень требует не более мощной модели, а большей готовности передать ответственность . Ступень Что делает машина Что требуется от вас 1. Тексты Письма, протоколы, ТЗ, разбор жалоб и договоров Внятно поставить задачу 2. Документы Читает PDF, сканы, длинные расшифровки, сравнивает версии Дать файл и вопрос к нему 3. Таблицы и данные Анализ выгрузок, аномалии, формулы, сводные срезы Выгрузку и понимание, что ищем 4. Изображения Читает скриншоты, схемы, фото документов Картинку и контекст 5. Подключения (MCP) Сама берёт данные из ваших систем: диск, таблицы, CRM Решить, какие доступы дать 6. Агентный режим Выполняет многошаговую работу: не «ответь», а «сделай» Регламент, границы и приёмку Первые четыре доступны в обычном чате с первого дня. И вот неприятная правда: подавляющее большинство руководителей застряло на первой ступени — просят тексты, получают тексты, делают вывод об инструменте целиком. Дело не в том, что они не умеют. Дело в том, что первая ступень — единственная, где ничего не надо решать: ни доступов, ни регламента, ни ответственности. Понимать, что можно передать машине, а что нельзя, — это новый управленческий навык. Не технический, подчёркиваю. Управленческий: он про делегирование и границы, а не про кнопки. Ступень 3: таблицы — то, что недооценивают почти все Про тексты знают все, про данные — почти никто. Claude принимает выгрузку из CRM, из учёта, из банка и отвечает на вопросы, ради которых обычно зовут аналитика: где просела конверсия по месяцам, какие клиенты дают 80% выручки, какие строки выбиваются и похожи на ошибку ввода. Пишет формулы для Excel и Google Sheets по описанию на русском — и объясняет чужие формулы, доставшиеся от уволившегося сотрудника. Два правила, которые мы вывели болью. Первое: машине нужна выгрузка, а не доступ «в голову» — данные выгружаем и обезличиваем. Второе: просите показывать логику расчёта, а не только ответ. Одна строка в постановке, а снимает половину рисков. Подробно, с готовыми постановками и разбором аномалий, — в статье про анализ таблиц . Ступень 5: MCP — машина сама ходит за данными Пока вы носите машине выгрузки руками, любая регулярная задача упирается в вас. «Сводка по зависшим сделкам каждый понедельник» означает, что кто-то каждый понедельник делает выгрузку. Автоматизация ломается не об ум машины, а об подноску данных. MCP (Model Context Protocol) — открытый протокол, который Anthropic опубликовала в конце 2024 года и который стал отраслевым стандартом. Аналогия простая: USB для ИИ. Один раз настраиваете коннектор — и машина сама читает нужное из диска, таблиц, календаря, CRM, в рамках выданных прав. Вопрос «какие сделки висят дольше двух недель и у кого» перестаёт требовать выгрузки. Оборотная сторона, которую я говорю всем: каждый коннектор — это выданный доступ, и относиться к нему надо как к доступу нового сотрудника. Права по минимуму, чтение раньше записи, боевые системы — в последнюю очередь. У нас машина читает, но в боевые системы не пишет до сих пор — это решение, а не техническое ограничение. Устройство, сроки настройки и правила безопасности — в детальном разборе MCP . Ступень 6: агенты — от «ответь» к «сделай» Верхняя ступень. В чате машина отвечает на реплику; агент получает цель и сам планирует шаги: читает данные, вызывает инструменты, проверяет промежуточный результат, доделывает. «Собери сводку по недельным продажам, сверь с планом, отметь отклонения больше 15% и подготовь черновик разбора» — четыре шага, которые агент проходит сам. Мой вывод из эксплуатации: агенты не «умнее», они самостоятельнее — и потому требования к постановке растут , а не падают. Агенту нужны границы (что нельзя), бюджет (сколько операций и денег вправе потратить) и точка приёмки. По сути — должностная инструкция. Компании с внятными регламентами встраивают агентов легче: у них половина работы уже сделана. Все три наших контура — это агенты с узкой специализацией; анатомия, инструкция и три типовых провала — в разборе про агентов . И раз уж речь о верхней ступени: у Anthropic есть собственная агентная среда — Claude Code. Родилась как инструмент разработчиков, но переросла в универсального исполнителя, который работает с файлами и системами напрямую. Инструменты этого класса стоят и за нашими контурами. Как выглядит рабочая задача Один пример из контура протоколов — чтобы было видно, чем рабочая постановка отличается от «сделай красиво»: Обратите внимание на «не придумывай». Без этой строки машина услужливо заполнит пропуски — назначит сроки, которых никто не называл. Такие мелочи и отличают работающий контур от красивого демо. Составлять такие постановки — отдельный навык, и в статье я его не преподаю: этому посвящён курс, ссылка в конце. Где ошибается — и где ошибался я Ошибается уверенным тоном. Неверная цифра, несуществующая ссылка на закон, додуманное обещание клиенту выглядят так же гладко, как правда. Частота ошибок невысокая, но место ошибки непредсказуемо — поэтому всё, что уходит наружу, проходит человека. Требует надзора, и это работа. Калибровки, разборы расхождений, обновление правил. Я писал об этом отдельно: автоматизация, которая требует надзора, — это вторая работа . Она легче первой, но она есть, и её надо закладывать в план. Не прощает небрежности с данными. Персональные данные клиентов и сотрудников в публичный чат не идут никогда. Обезличиваем: не «Иванов Пётр, +7 916…», а «клиент К., постоянный, чек 180 тыс.». На качество ответа не влияет, а штрафы за утечки с 2026 года выросли кратно — разбор правовой стороны . Где ломается Самый дорогой сценарий — не ошибка машины, а отсутствие приёмки: текст с непроверенной цифрой ушёл клиенту, потому что «нейросеть же написала». Живой сотрудник ошибается не реже — просто его черновики принято вычитывать, а машинные почему-то нет. Правило простое: у каждого результата машины есть человек с фамилией, который его принял. Как отличить работающий контур от красивого демо Вам будут показывать ролики: агент бронирует переговорку, пишет стратегию, «заменяет отдел». Три вопроса, которыми я пользуюсь сам. Где цифры за месяц, а не за минуту? Демо показывает одну удачную операцию, эксплуатация — распределение: сколько прошло, сколько вернулось на доработку, сколько стоил месяц. Наши 7 139 оценок — это и есть ответ на вопрос «что будет, если гонять каждый день», включая неудобную часть: выяснилось, что обрезанный транскрипт машина оценивает как полный, и это пришлось ловить отдельной проверкой. Кто принимает результат? Если в демо нет человека на приёмке — либо цена ошибки нулевая, либо вам не договаривают. Что происходит при сбое? У настоящего контура есть ответ: очередь повторов, уведомление, деградация в ручной режим. Демо при сбое перезапускают за кадром. Этот же фильтр работает и на себя. Не можете ответить на три вопроса по своему пилоту — он ещё не в эксплуатации, что бы ни показывали слайды. Почему большинство застревает именно здесь — разбор с пятью типовыми ошибками . Кому это пока не нужно Для равновесия — три случая, когда закрывайте вкладку и занимайтесь другим. Если в работе нет текстового потока — писем, документов, расшифровок, отчётов, — выгода будет косметической: нейросеть для работы с текстом окупается объёмом текста, а не самим фактом покупки. Если некому принимать результаты — машина без приёмки не экономит время, а создаёт риск. И если задача звучит как «поднять продажи вообще» — нейросеть не стратегия, она исполнитель: ускорит понятные операции, но не придумает за вас, какие операции нужны. Что сделать сегодня Не внедрять. Не покупать корпоративный тариф. Сделать три вещи за вечер. Первое. Откройте чат и прогоните одну настоящую задачу — не тестовую. Письмо клиенту в сложной ситуации, разбор входящего договора, протокол вчерашней планёрки. Настоящую: с вашим контекстом и вашими требованиями к результату. Второе. Посмотрите на лестницу выше и честно отметьте, на какой ступени стоите. Если на первой — вы не «попробовали ИИ», вы посидели в машине на парковке. Третье. Выберите одну повторяющуюся задачу, которая съедает у вас от получаса в неделю. Это ваш кандидат на вторую ступень, а через пару месяцев — на контур. Дальше механика: данные и таблицы , подключения к системам , агенты . А если хочется не собирать по кускам, а пройти путь по порядку — у меня есть бесплатный курс для руководителей : от разбора собственной рутины до первого работающего контура, без программирования. И главное. Год назад я был там же, где вы сейчас, — с ощущением, что это раздутая тема для айтишников. Сегодня три участка работают без меня, а я занимаюсь тем, чем должен заниматься директор. Разница между этими двумя точками — не в бюджете и не в гениальности. В одном вечере, с которого начинается счёт.

## Как управлять бизнес-процессами: от описания до автоматизации
URL: https://davidgerstein.pro/operacii/upravlenie-biznes-processami/
Дата: 2026-08-27
Направление: Операционное управление
Цифры: риск зависших сделок 900 000 → 540 000 ₽/мес (оценка) · снижение риска на 40%
Коротко: Управление бизнес-процессами — это не документ на полке, а цикл «описал → нашёл узкое место → автоматизировал именно его». В компании с оборотом 9 млн ₽/мес узкое место в воронке держало риск зависших сделок на уровне 900 000 ₽/мес (оценка); после того как нашли стадию и назначили владельца, риск снизился до 540 000 ₽/мес (оценка). При этом 71% компаний уже применяют ИИ в процессах, а значимый финансовый эффект фиксируют только 9% — разница не в инструменте, а в том, доведён ли разбор до метрики и человека, который за неё отвечает.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете назвать, сколько дней ваш заказ идёт от заявки до денег, — у вас нет процесса. У вас есть привычка, которую каждый исполняет по-своему, и вы узнаёте о сбое от клиента. Описывать все процессы компании — плохая идея: вы потратите квартал и получите папку, которую никто не откроет. Начинать надо с одного процесса, который приносит вам больше всего боли. Что такое управление бизнес-процессами на практике Это не документ на полке, а цикл: описать как есть → найти узкое место → поставить норматив → автоматизировать → мерить. Процесс без норматива срока не управляется: в компании на 40 человек сделка провисела 540 дней и всё это время считалась живой. Автоматизация даёт эффект только после описания: она ускоряет то, что есть. В том же отделе продаж риск зависших сделок снизился с 900 000 до 540 000 ₽/мес — не потому что купили систему, а потому что появились дни в статусе и ответственный на каждом этапе. Скажу сразу, чего мне самому не хватало, когда я брался за это впервые: не методики, а понимания, что описывать процесс целиком не нужно. Мне казалось, что пока не опишу всё, начинать нельзя — и я не начинал. Когда вам это действительно нужно Признак простой: вы перестали помнить, как именно у вас происходит работа от заявки до денег, и вам приходится спрашивать. Управление бизнес-процессами — это не регламент и не схема в презентации. Это три действия по кругу: описать, кто что делает и сколько это занимает; найти стадию, где всё стоит дольше нормы; автоматизировать именно эту стадию, а не процесс целиком. Нужно это тогда, когда компания выросла настолько, что никто больше не помнит всю цепочку наизусть — по моим наблюдениям, это происходит где-то между 25 и 40 сотрудниками. Масштаб проблемы виден в одной цифре, и она неприятная. По исследованию «Яков и Партнёры» (2026) ИИ в процессах уже применяют 71% компаний, но значимый финансовый эффект фиксируют только 9%. При этом 89% таких проектов остаются пилотами — данные TAdviser и MWS AI, 2026, 2026 — запустили, показали на демо, забыли. Разница между 71% и 9% — это не про модель и не про бюджет. Это про то, довели ли разбор до конкретной метрики и до человека, который за неё отвечает. Ещё одна цифра, из исследования SpeShu.AI по малому и среднему бизнесу (86 глубинных интервью, 2026): 47% руководителей принимают решение о масштабировании ИИ-инициатив по кейсам с измеримыми результатами, а не по описанию функционала на демо. Проблема в том, что публичных кейсов с прозрачной экономикой на рынке почти нет: конкуренты по кругу повторяют одни и те же четыре цифры — «−30–50% рутины», «до 80% операций», «−40% издержек», «окупаемость 3–6 месяцев» — без единого числа, которое можно взять и проверить на своих данных. Этот гайд собран так, чтобы цифры можно было пересчитать: с ценой внедрения, а не только с эффектом, и с отдельным разделом про то, где расчёт не сработал. Управление процессами не равно регламентам на полке: сам по себе документ ничего не меняет, если по нему не сверяются. И это не разовый аудит: без цикла повторения любой аудит устаревает за один квартал. Как описать процесс, чтобы его можно было анализировать Ваша задача — не красивая схема, а пять-семь шагов со временем каждого. Схему нарисуете потом, если понадобится. Процесс описан достаточно, если по нему можно посчитать время каждого шага и назвать одного ответственного за шаг. Три поля минимум: шаг, кто делает, сколько занимает. Без числа «сколько занимает» описание — это красивая картинка, а не рабочий инструмент. Самый быстрый способ получить такое описание — не сажать человека за Excel на день, а дать ему полчаса и голос. Рабочая механика, которую я видел не раз: руководитель просит менеджера наговорить дорожную карту по воронке — что есть на каждой стадии сейчас, что работает, что нужно внедрить, — а потом это передают тому, кто расписывает автоматизации. Полчаса голосом дают больше, чем два часа мучений с таблицей: человек не редактирует себя на лету и не забывает мелкие детали, которые обычно выпадают при формальном описании. Готовое описание бесполезно, если оно не привязано к живому месту хранения, которым реально пользуются — про это подробно: дом без дверей: как сделать базу знаний, которой реально пользуются . Там разбор, почему один и тот же процесс на бумаге и в базе — это два разных процесса. Описание процесса и регламент по нему — разные документы с разной судьбой. Описание фиксирует, как есть сейчас; регламент диктует, как должно быть, и его гораздо чаще кладут на полку и забывают. Чтобы регламент не превращался в мёртвый текст, важны те же три поля, что и в описании, плюс явный критерий готовности каждого шага — как сделать регламент, который реально читают: регламенты, которые читают: от полки к инструменту . Отдельно стоит зафиксировать формат хранения самого описания — версию, дату последнего обновления и того, кто внёс правку. Без этих трёх полей описание живёт ровно до первого спора: два человека приносят на встречу два разных файла с одинаковым названием и разными шагами, и никто не может сказать, какой из них актуальный. Простое правило «одна ссылка — один актуальный файл» закрывает эту проблему почти полностью, но требует дисциплины именно от того, кто процесс описывал, а не от всех подряд. Где ломается. Описание живёт, если по нему сверяются хотя бы раз в квартал. Если не сверяются — оно превращается в документ, который читают один раз при найме и больше никогда. Как найти узкое место: метрики, а не ощущения Спросите своих людей, где им тяжелее всего, — а потом проверьте цифрами. В моей практике эти два ответа совпадали примерно в половине случаев. Узкое место — это стадия процесса, где доля объектов (сделок, заявок, документов), стоящих дольше нормы, превышает 20–25% от числа объектов на этой стадии . Знаменатель тут решает всё: считать надо от того, что стоит на стадии сейчас, а не от всего месячного потока — иначе любая стадия выглядит благополучной и узкое место не находится никогда. Находится это выгрузкой времени прохождения по стадиям из CRM за месяц, а не опросом «где у нас тормозит» — на опрос каждый отдел честно скажет, что тормозит у соседей. Пример на цифрах нашей условной компании. Оборот 9 млн ₽/мес при среднем чеке 180 тыс. ₽ — это 50 сделок в месяц на 8 менеджеров, то есть около 6 сделок на менеджера. Выгрузка по стадиям показала: на согласовании находятся 12 сделок, и 5 из них стоят дольше нормы — это 42%, вдвое выше порога. Риск таких зависших сделок = 5 × 180 000 = 900 000 ₽/мес (оценка) — не выручка, которую точно потеряют, а сумма, которая под угрозой, если сделки не разморозить. Как считать риск зависших сделок (формула, не готовый вывод для любой компании) Берём одну стадию — ту, что признана узким местом. Знаменатель тот же, что и в диагностике: сделки, находящиеся на этой стадии, а не месячный поток. Зависших сделок = сделок на стадии × доля стоящих дольше нормы (целыми штуками, не «2,5 сделки»). Риск = зависших сделок × средний чек. Пример: на согласовании 12 сделок; 12 × 42% ≈ 5 сделок; 5 × 180 000 ₽ = 900 000 ₽/мес (оценка). После того как на стадию согласования назначили владельца и поставили ежедневный алерт о сделках старше 10 дней, доля стоящих дольше нормы упала с 42% до 25% — с 5 сделок до 3. Риск снизился с 900 000 ₽ до 540 000 ₽/мес, то есть на 360 000 ₽/мес (оценка). Это снижение риска, а не гарантированный прирост выручки: часть из этих сделок и без вмешательства закрылась бы сама. На диаграмме — риск зависших сделок до и после того, как нашли стадию и назначили владельца. 900 000 до 540 000 после Риск = число зависших сделок × средний чек (180 000 ₽). Было 5 сделок, стоящих дольше нормы, из 12 на стадии (42%), стало 3 из 12 (25%) — снижение риска на 360 000 ₽/мес, оценка. Стадия Сделок на стадии Стоят дольше нормы, до % до Стоят дольше нормы, после % после Согласование 12 5 42% 3 25% Договор 8 2 25% 2 25% Оплата 6 1 17% 1 17% Важная деталь про эту таблицу: доли на стадиях «Договор» и «Оплата» не изменились — там узкого места не было и мы туда не вмешивались. Это специально: автоматизация точечная, а не «давайте улучшим всё сразу». Если начать чинить сразу все стадии, ресурсов и внимания владельцев не хватит ни на одну, и через месяц окажется, что метрика не двинулась ни там, ни там. Где ломается. Если метрику посчитали один раз и не обновляют, узкое место «находят» заново каждый квартал вручную, а разные выгрузки одного и того же показателя расходятся почти в 5 раз — подробный разбор с цифрами: узкие места в процессах: как найти то, что тормозит всю компанию . Кого назначить владельцем Того, кто видит ваш процесс каждый день и может на него влиять. Не топ-менеджера «для веса» — иначе владелец будет узнавать о проблемах последним. У каждого процесса должен быть один именованный человек, который отвечает за метрику стадии — не отдел, не «продажи в целом», а конкретная должность. Без этого любая автоматизация превращается в надзор вручную: бот шлёт алерты, а разбираться с ними всё равно приходится тому, кто случайно их заметил. На одной из планёрок операционный директор Лена задала простой вопрос: «Кто владелец этого процесса?» — про стадию согласования договоров. Молчание длилось секунд десять. Отдел продаж считал, что это забота юристов; юристы — что это забота продаж; проект-менеджер думал, что процесс вообще ничей, потому что документооборот всегда «как-то сам разбирался». Через неделю владельца назначили — и оказалось, что у него физически нет времени на эту роль: он уже вёл три параллельных проекта. Роль пришлось переносить на другого человека. Сам разговор о том, кто владелец, стоит фиксировать не в памяти участников планёрки, а в протоколе, который не зависит от того, кто что запомнил через неделю. Мы стали автоматически расшифровывать планёрки в текст именно из-за таких историй: раньше на следующей неделе каждый вспоминал разговор по-своему, и спор шёл не по делу, а по памяти. Механика такой автоматизации — в разборе: планёрка, которая документирует себя сама . Автоматизация без владельца почти всегда требует надзора — сколько это стоит в деньгах и какие три свойства обязательны у рабочей автоматизации, разбирали здесь: «если бы я не пришёл, ничего бы не произошло» . А как выстроить контроль, который не держится на памяти одного человека — в разборе про делегирование: делегирование без хаоса . Ещё одно наблюдение по этой теме: должность владельца не должна плыть по тексту документов компании. Если в одном регламенте он «руководитель отдела продаж», а в другом — «ответственный за воронку», через полгода никто не может быстро найти, кто это. Зафиксируйте должность один раз в одном месте и ссылайтесь на неё, а не переизобретайте название роли под каждый новый документ. Где ломается. Владелец назначен формально, но перегружен другой работой — роль превращается в фикцию, а метрика продолжает расти в тишине. Какие каналы связи незаметно душат процесс Разросшиеся каналы связи не ускоряют процесс — они прячут узкое место, потому что информация расползается по местам, которые никто не сверяет между собой. Типичный симптом: число оплаченных каналов вырастает в разы без роста числа сотрудников, которые ими пользуются. Реальный случай: в апреле было оплачено 7 каналов связи, в мае — уже 52, хотя на каждого сотрудника при этом просто задублировали WhatsApp и Telegram по отдельным тарифам, реально работая в одном из двух. Такая переплата обычно всплывает вместе с зависшими сделками — оба симптома растут из одного и того же неконтролируемого процесса. За этим ростом почти всегда стоит одна и та же причина: у канала связи, как и у процесса, должен быть владелец, который отвечает за состав подключений, а не просто оплачивает счёт по факту. Пока эту роль не зафиксировали письменно, разрастание каналов идёт быстрее, чем любой квартальный аудит успевает его заметить. Проверка, которая занимает 15 минут раз в месяц и почти всегда себя оправдывает: выгрузить список активных подписок на связь из бухгалтерии, сверить с числом реально работающих сотрудников и спросить прямо — «этот канал кто-то использует сегодня, или это наследство от прошлого сотрудника, которого уже нет в компании». Обычно один такой вопрос закрывает 3–5 ненужных подписок за раз. Где ломается. Аудит каналов делают раз в год «для отчётности», а разрастание происходит за один-два месяца — к следующей проверке всё уже вернулось на исходную. С чего начать за одну неделю Минимальный рабочий контур на неделю — это не «внедрить систему управления процессами», а четыре конкретных действия: выбрать один процесс, выгрузить по нему цифры, назначить владельца, поставить один автоматический алерт. Дальше — по результатам первой недели решать, что делать со вторым процессом. Понедельник — выбрать процесс. Не тот, что кажется важным вам, а тот, на который чаще жалуются клиенты или коллеги: спросите прямо на планёрке. Вторник и среда — выгрузка из CRM: время прохождения каждой стадии за 30 дней, медиана и доля тех, кто застрял дольше нормы. Четверг — вслух назвать владельца стадии, где дольше нормы стоит больше 20% находящихся на ней сделок. Пятница — включить один алерт (вебхук в Bitrix24 или формула в Google Sheets), который сам напомнит о превышении нормы, — и на этом неделя заканчивается, дальше идёт по результатам. Вот как может выглядеть дашборд, который собирает владелец процесса после этой недели — те же цифры по стадии согласования, что и на диаграмме выше, но в виде рабочего экрана. Мониторинг: риск зависших сделок 12 сделок на согласовании 42%→25% стоят дольше нормы на согласовании 900 000→540 000 ₽ риск зависших, оценка Стадия Стоят дольше нормы Статус Согласование 25% (было 42%) Договор 25% Оплата 17% Дашборд не заменяет живой разговор на планёрке — он его сокращает. Раньше на обсуждение этой стадии уходило 20–30 минут, потому что цифры собирали на ходу устно; с готовым экраном на это нужно 5 минут — цифры уже перед глазами у всех, спорить не о чём, обсуждать можно сразу решение. Где ломается. Пытаются сразу описать все процессы компании — и застревают на описании, не доходя до автоматизации ни одного. Лучше один процесс за неделю, чем десять за квартал без результата. ИИ-связка: три промпта под разные задачи процесса Для управления процессами нужно минимум три разных промпта на трёх разных этапах: найти узкое место в данных (дешёвая модель, потому что задача формальная), оценить качество взаимодействия по чек-листу (дорогая модель, потому что нужно понимать контекст диалога), проверить структуру документа перед публикацией (снова дешёвая модель, задача техническая). Смешивать их в один универсальный промпт — способ получить средний результат по всем трём направлениям. Промпт 1 — найти узкое место в воронке (amoCRM API, дешёвая модель для классификации). На входе — выгрузка сделок с полями стадии и датами входа-выхода. Пример ответа модели: Промпт 2 — оценить звонок по внутреннему чек-листу (дорогая модель, нужен разбор смысла разговора). На входе — транскрипт звонка менеджера с клиентом. Пример ответа модели: Дорогую флагманскую модель для этой задачи иногда берут по привычке, хотя более дешёвая версия на том же промпте давала идентичный результат — мы проверяли на одних и тех же текстах, разницы не было. При десятках звонков в день экономия на токенах ощутимая, а дорогую модель стоит держать для случаев сложнее — например, для разбора конфликтных диалогов. Промпт 3 — проверить структуру документа перед публикацией (Google Диск + скрипт-триггер, дешёвая модель). На входе — текст инструкции или регламента. Пример ответа модели: Такая проверка снимает необходимость перечитывать документ на 20 страниц вручную каждый раз, когда его редактируют: автор загружает файл на Google Диск, триггер запускает скрипт, отчёт приходит в Telegram за минуту. Общее правило для всех трёх промптов: они возвращают только цифры и факты, без выводов и рекомендаций. Решение — чинить стадию, менять скрипт разговора или дописывать раздел документа — всегда принимает человек-владелец. Если дать модели право сразу советовать «что делать», решения начинают приниматься без разбора контекста, а ответственность за результат размывается между человеком и моделью так, что спросить потом не с кого. Экономика: что стоит автоматизация узкого места и что она даёт Настройка мониторинга одной стадии процесса занимает около 8 часов работы аналитика, эксплуатация — примерно 1 500 ₽/мес на API и хранение данных, а эффект от снижения риска зависших сделок в разобранном примере ≈ 360 000 ₽/мес (оценка). Отдельно от этого экономия часов на ручной сверке — около 20 000 ₽/мес (оценка). Это две разные строки, складывать их в один «эффект» нельзя: одна показывает снижение риска, другая — освободившееся время сотрудника, переведённое в деньги. Статья Часы / сумма Комментарий Настройка выгрузки и алерта ~8 часов разово труд аналитика или подрядчика, ставка ~1 500 ₽/час Разовая настройка, итого ~12 000 ₽ оценка Эксплуатация ~1 500 ₽/мес API, хранение, лёгкий скрипт-триггер Экономия часов на ручной сверке ~20 часов/мес × 1 000 ₽/час ≈ 20 000 ₽/мес оценка, поток, не разовая сумма Снижение риска зависших сделок ~360 000 ₽/мес оценка, это не гарантированная прибыль Посчитайте риск зависших сделок на своих цифрах — формула та же, что и в разобранном примере: сделки в месяц × средний чек × доля зависших. посчитайте на своих цифрах сделок на стадии средний чек, ₽ % стоящих дольше нормы риск ≈ {X} ₽ в месяц формула: сделки на стадии × доля стоящих дольше нормы, округление вниз до целых сделок, × средний чек; это оценка сверху, а не гарантированная потеря Пример с подстановкой: на стадии согласования 12 сделок, средний чек 180 тыс. ₽, доля стоящих дольше нормы падает с 42% до 25% — это 2 сделки, которые раньше стояли бы дольше нормы. 2 × 180 000 ₽ = 360 000 ₽/мес риска, который перестаёт висеть (оценка). Окупаемость по консервативной части (только экономия часов 20 000 ₽/мес против разовых 12 000 ₽ настройки) — меньше месяца. Окупаемость по риску в месяцах не считаем: это не гарантированный денежный поток, а вероятность потери, которая снизилась. Если в компании узких мест несколько, считать риск нужно по каждой стадии отдельно, а не суммировать риски всех стадий в одну общую цифру: риски по разным стадиям почти всегда частично перекрывают одни и те же сделки, и сложение задвоит проблему. Начинайте с той стадии, где абсолютная сумма риска больше — обычно это не самая заметная стадия по числу жалоб, а та, где чек выше среднего. Что мы не считаем эффектом. Если освободившиеся от ручной сверки часы никуда не пошли — просто «стало свободнее», а нагрузка не изменилась, — деньги здесь считать нельзя. Это перераспределение времени, а не эффект в кассе; фиксируйте его отдельно и проверяйте через квартал. Ещё одно уточнение по этой таблице: снижение риска зависших сделок — результат связки из двух мер, назначенного владельца стадии и автоматического алерта, а не одного алерта отдельно. Разделить их вклад по отдельности честно нельзя: без владельца алерты просто копились бы непрочитанными, без алерта владелец не знал бы, когда вмешаться. Пишем это прямо, а не выдаём эффект связки за эффект одного инструмента. Где это не сработало у меня Голосовые роботы для обзвона клиентов — пример автоматизации, которая заработала технически, но не окупилась экономически: при нашем объёме звонков срок окупаемости превышал два года. Мы отказались от разработки внутри и взяли оператора на часть ставки — дешевле и быстрее. Разработка «естественной» речевой системы требует записи тысяч комбинаций диалогов и обучения нейросети на них — это отдельный проект, а не настройка на пару часов. По прикидкам, она стоила бы около 350 000 ₽ разово (оценка) плюс постоянные правки под новые сценарии. Задача, которую должен был решать робот, — обзвон с напоминанием об оплате, около 50 звонков в месяц по 15 минут, то есть 12,5 часов человеческого труда; при ставке 1 000 ₽/час это 12 500 ₽/мес (оценка). Разовые 350 000 ₽ на робота против 12 500 ₽/мес живого оператора — вот и весь расчёт по срокам. Вторая история: без явного владельца автоматизация требует надзора буквально — бот слал алерты о зависших сделках три недели, но их читали и забывали, пока ответственного не назначили письменно. Третья история короче, но обиднее: мы автоматизировали сбор отчётов по звонкам через речевую аналитику, а разбираться в присланных цифрах всё равно приходилось руководителю отдела вручную — формат выгрузки не совпадал с тем, как он привык читать отчёт, и он просто пересобирал всё заново в своей таблице. Технически система работала правильно. Просто никто не спросил заранее, в каком виде человек реально готов эти цифры принимать. Общая причина у всех трёх провалов одна: мы запускали инструмент, а не решали измеримую заранее задачу, и цель либо не была сформулирована в цифрах, либо была занижена настолько, что успех и провал было невозможно отличить друг от друга. Пять типовых ошибок, из-за которых технически работающий проект не даёт результата, разобраны здесь: почему внедрение ИИ не работает — хотя технически всё запустилось . Зрелость по уровням: старт, квартал, год Зрелость управления процессами измеряется не количеством внедрённых инструментов, а тем, есть ли у компании привычка регулярно возвращаться к описанному процессу и перепроверять метрику. На старте достаточно одного описанного процесса и одной цифры; через квартал — системы алертов и владельцев на ключевых стадиях; через год — регулярного аудита, который проводится по календарю, а не по случаю. Старт (0–1 месяц). Один процесс описан в таблице «шаг — ответственный — время». Найдено одно узкое место по цифрам, а не по ощущениям. Назначен владелец стадии. Квартал (3 месяца). Автоматизирован мониторинг зависших сделок или задач хотя бы на одной стадии. Введён регулярный (не разовый) аудит каналов связи. У 2–3 ключевых процессов есть именованные владельцы, а не «отдел в целом». Год. Работает связка дашбордов по нескольким подразделениям, а не только по продажам. Регламенты действительно читают, а не держат на полке. Планёрки документируются автоматически, и это освобождает часы менеджеров. Ручные ежедневные отчёты, на которые раньше уходило по 30 минут в день, автоматизированы — что стоит за этими получасами, если их никто не считал заранее, показано в заметке: во что выливаются полчаса ручного отчёта, который никто не считал . Между уровнями нет жёсткой границы по календарю — есть граница по признаку. Компания переходит со старта на квартальный уровень не по календарю, а тогда, когда первое узкое место разобрано до конца: владелец назначен, метрика стабилизировалась, алерт работает без напоминаний. Если этого не произошло, лучше остаться на уровне старта дольше и не хватать второй процесс — распылённое внимание хуже, чем медленный, но доведённый до конца один разбор. Где ломается. Компания перескакивает со старта прямо на «год» — покупает дорогой дашборд без единого описанного процесса под ним. Инструмент работает, но показывает цифры, которым никто не доверяет, потому что источники данных не сверены. Чек-лист первого понедельника Выбрать один процесс с наибольшим числом жалоб за последний месяц. Выгрузить из CRM время прохождения каждой стадии этого процесса за 30 дней. Посчитать долю сделок или задач, застрявших дольше нормы на каждой стадии. Назвать вслух на планёрке: «Владелец этой стадии — [конкретное имя]». Настроить один автоматический алерт о превышении нормы (Bitrix24-вебхук, Google Sheets с формулой или Telegram-бот). Зафиксировать текущую сумму риска зависших объектов как точку отсчёта — сравнивать с ней через месяц. Поставить в календарь повторную проверку через 4 недели — без этого пункта всё остальное держится только на энтузиазме. Ваш первый шаг на этой неделе: выберите процесс, на который у вас больше всего жалоб, и опишите его в пять-семь шагов с временем каждого. Дальше вы сами увидите, что чинить. Как связать описание с автоматизацией и не увязнуть в бумажной работе — в бесплатном курсе . С чего начать именно вам Не пытайтесь описать всё. Возьмите один процесс, который вас раздражает больше всего, и пройдите по нему сами — от начала до конца, вместе с вашими людьми. Отметьте, где ждут, где переспрашивают, где переделывают. Дальше у вас будет выбор: чинить организационно или автоматизировать. И в вашем случае, скорее всего, первое даст результат быстрее. И про навык, ради которого всё это. Читать процесс по цифрам — дни на этапе, доля возвратов, кто ответственный — такой же базовый навык руководителя, как читать отчёт о прибылях. Я сам годами обходился без него: спрашивал у людей «как идёт» и получал ответ «нормально». Нормально означало 540 дней у одной сделки. Пока вы не видите процесс числами, вы им не управляете — вы его сопровождаете.

## Внедрение ИИ: три развилки, на которых ломаются девять из десяти
URL: https://davidgerstein.pro/operacii/vnedrenie-ii-v-biznese/
Дата: 2026-08-31
Направление: Операционное управление
Цифры: 3 развилки · пилот от десятков долларов · 2–3 месяца до устойчивой пользы
Коротко: Внедрение ИИ проваливается не на технологии. Технически контур запускается за две-три недели и стоит десятки долларов через API; ломается всё на трёх управленческих развилках: какой процесс взять первым (частый, а не самый больной), кто внутри компании принимает работу машины (без имени — нет внедрения) и когда отключается старый способ работы (пока живут обе схемы, команда держится за привычную). В компании на 40 человек три работающих контура: оценка 100% звонков за ~$300 в месяц, разбор документов 79 типов с точностью 85%, протоколы планёрок с экономией порядка 70 часов в месяц. И один честный провал: 7 139 оценок, из которых в решения превратилась одна.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы дочитали до решения «надо внедрять» — самое опасное одновременно позади и впереди. Позади сомнения. Впереди три развилки, на которых ломаются девять внедрений из десяти, и ни одна из них не техническая. Я прошёл эти развилки трижды: контроль звонков, разбор документов, протоколы планёрок. Два раза с ошибками, о которых расскажу честно. Ниже — маршрут, по которому можно пройти быстрее меня. Что такое внедрение ИИ и сколько оно занимает Внедрение ИИ — это перевод одного повторяющегося процесса на машинного исполнителя с сохранением человека на приёмке. Технически контур запускается за две-три недели, до устойчивой пользы проходит два-три месяца: неделя ручных прогонов, неделя-две теневого режима со сверкой, месяц эксплуатации с плотной приёмкой. Пилот через API стоит десятки долларов. Настоящая цена — часы руководителя на калибровку и приёмку. Контур оценки звонков в компании на 40 человек обходится примерно в $300 в месяц на весь поток разговоров отдела продаж. Почему технология — не проблема Смотрите, что обычно происходит. Компания решает внедрять ИИ, зовёт подрядчика, тот показывает демо, называет сроки и сумму. Через полгода проект тихо сворачивается: технически всё работало, но люди продолжили делать по-старому. Это не редкость и не невезение — это правило. Технология сегодня доступна и дешева: модель покупается, инструменты открыты, вход стоит десятки долларов. Собрать работающий контур — задача на недели. А вот заставить компанию перестать работать по-прежнему — задача на месяцы, и она не решается ни бюджетом, ни подрядчиком. Поэтому весь этот гайд — про управленческую часть. Технику я разбираю в других материалах: как устроен ИИ-агент и как подключить машину к вашим системам . Технически запустились 10 из 10 Дошли до плотной приёмки ~4 Отключили старый способ 1–2 Пропорция на схеме — не статистика рынка, а то, что я вижу вокруг себя и в собственных проектах: запуск даётся всем, доводит до конца меньшинство. Дальше — три места, где теряются остальные. Развилка первая: какой процесс взять первым Здесь ошибаются чаще всего, и ошибка выглядит логичной: берут самое больное. Отдел, где хуже всего, процесс, который раздражает сильнее прочих. Разумно — и почти всегда неверно. Больное обычно потому и больное, что сложное: там нет правил, нет данных, есть конфликт между людьми. Машина в такой ситуации не спасает, а обнажает — и вы получаете разочарование раньше первого результата. Правильный критерий — три признака сразу: Признак Как проверить у себя Поток Задача повторяется десятки раз в неделю. Пять звонков или три договора в месяц машине отдавать незачем Проверяемое правило Вы можете письменно описать, что считается хорошим результатом. Не получается за полчаса — правил нет, есть привычка конкретного человека Получатель Есть человек, которому результат нужен регулярно и который заметит, если его не будет Наш первый контур — оценка звонков — подошёл по всем трём: 120 разговоров в день, чек-лист качества и руководитель отдела продаж, которому нужны разборы. А вот попытка начать с чего-то более «стратегического» у меня провалилась бы: там нет ни потока, ни проверяемого правила. И отдельно про должности-призраки. Самые быстрые деньги лежат не в отнятой у людей работе, а в той, которую у вас не делает никто : слушать все звонки, читать все входящие договоры, сводить отчёт каждое утро. Там нет сопротивления команды — вы не забираете ничью работу, вы закрываете дыру. Если кандидатов несколько и все выглядят достойными — прогоните каждого через тест из четырёх вопросов: как выбрать первый процесс для автоматизации . Там же разобрано, почему мой самый больной процесс идёт четвёртый месяц, а взлетел совсем другой. Развилка вторая: кто отвечает внутри Теперь неприятная часть, которую подрядчики не проговаривают. Внедряя ИИ, вы получаете в компанию не минус позицию, а плюс две: машину-исполнителя и человека, который ею руководит. Пишет инструкцию, калибрует, принимает работу, разбирает расхождения. Машина не отвечает ни за что — спросить с неё нельзя, уволить бессмысленно. Кого именно назначить и три обязанности, которые нельзя передать подрядчику, — в разборе «Специалист по внедрению ИИ: кого назначить внутри компании» . Там же цифра, объясняющая цену отсутствия хозяина: разрыв в калибровке −25,5 п.п., замеренный ровно один раз. Этот человек — не ИТ-отдел. ИТ поставит и настроит, но принимать результат должен владелец процесса: руководитель продаж для оценки звонков, руководитель операций для разбора документов. Тот, кто заметит, что оценки перестали соответствовать реальности, и кому есть дело до того, чтобы они превращались в решения. Вести внедрение — это не ИТ-компетенция. Это управленческий навык: поставить проверяемую задачу, принять работу, вовремя отключить старый способ. Осваивается на первом же контуре, но кем-то в вашей компании — осваивается. Где ломается Проверка перед стартом ровно одна: назовите имя человека, в чьём календаре появятся приёмка и разборы. Не отдел, не роль — имя. Если его нет, вы покупаете не внедрение, а дорогую имитацию: контур будет исправно работать в стол. Знаю по себе: наш контур оценки звонков выдал 7 139 оценок при одном содержательном отзыве . Разбор этого провала — там же. Инструкция такого человека для машины выглядит буднично — вот каркас, который вы заполните под свой процесс: Сравните с должностной инструкцией сотрудника — совпадение почти дословное. И если написать такую инструкцию не получается, вы узнали о своём процессе главное: правил в нём нет, есть привычка конкретного человека. Это неприятно, но обходится в неделю, а не в бюджет внедрения. Развилка третья: когда отключается старый способ Это то, о чём почти не говорят, а между тем именно здесь умирает большинство внедрений. Пока новый и старый способ работы живут параллельно, команда держится за привычный. Не из вредности: привычный понятен, за него не спросят, он не требует учиться. В итоге компания платит дважды — за машину и за прежний ручной труд, — а эффекта нет ни от одного. Признак, по которому вы отличите живое внедрение от умирающего: назначена ли дата, после которой старый способ перестаёт работать. Не «постепенно перейдём», а конкретное число в календаре. У нас это выглядело так: месяц параллельной работы — контролёр слушала звонки и машина оценивала, расхождения разбирались. Потом дата: с такого-то числа ручная выборочная проверка остаётся, а сплошное прослушивание прекращается. Без этой даты мы бы до сих пор делали и то и другое. Оговорка: отключать можно только после калибровки. Дата назначается не в начале, а в момент, когда цифры показали, что машине можно доверять на этом участке. Подробнее про типовые ошибки этого этапа — в разборе умирающих внедрений . Маршрут внедрения ИИ: два-три месяца по неделям Откуда берутся именно эти два-три месяца и почему у одних выходит 6 недель, а у других полгода при той же работе подрядчика — посчитал в разборе «Внедрение ИИ в компании: сколько времени занимает» : срок меряется циклами приёмки, а их длина целиком в вашем календаре. Этап Что происходит Результат Неделя 1 Ручные прогоны Процесс гоняется в чате руками, на реальных данных. Выясняется, какие правила вы забыли сформулировать Черновик инструкции и список границ Недели 2–3 Теневой режим Машина работает автоматически, результат никуда не идёт — только сверяется с человеческим Цифра доверия вместо ощущения Недели 4–7 Плотная приёмка Результат используется, человек смотрит всё. Всплывают редкие случаи Отлаженные границы, назначенная дата отключения Неделя 8+ Рабочий режим Старый способ отключён, приёмка выборочная и по пометкам машины Контур в эксплуатации Быстрее бывает, но обычно это значит, что пропущен теневой режим — и тогда вы узнаёте о качестве от клиентов, а не от сверки. Что делать с сопротивлением команды Вопрос, который вам зададут раньше технических: «нас что, заменяют?» И от вашего ответа зависит, будет внедрение идти или буксовать. Отвечать надо до старта и честно. Если машина закрывает работу, которую никто не делал, — так и скажите: контроль всех звонков вместо четверти, разбор всех документов вместо выборки. Никто не теряет места, закрывается дыра. Это правда, и её легко проверить. Если же машина забирает часть чьей-то работы — не прячьте это. Скажите, что освободится время, и назовите, на что оно пойдёт. Люди боятся не машины, а неизвестности: непонятно, что будет со мной через квартал. И приём, который снял у нас больше сопротивления, чем все объяснения: делать оценку прозрачной, чтобы её можно было проверить. Как именно — в разборе про внедрение контроля без саботажа . Сколько это стоит на самом деле Три части, и первая — самая маленькая. Операции. Через API это центы за операцию. Наш контур оценки звонков — примерно $300 в месяц на весь поток отдела продаж, то есть около 9 ₽ за разговор против ~130 ₽ при ручной работе контролёра (оценка). Пилот, чтобы просто попробовать, стоит десятки долларов. Настройка. Разовая: описать типы, собрать связку, настроить подключения. Дни или недели работы, в зависимости от того, есть ли у вас разработчик. У нас на разбор документов ушла неделя только на описание 79 типов — и это была основная работа, а не программирование. Внимание руководителя. Здесь настоящие деньги. Первые месяцы это часы каждую неделю: калибровка, разбор расхождений, обновление правил. Дальше меньше, но в ноль не сворачивается никогда . посчитайте цену вашего процесса вручную операций в месяц минут на операцию ставка исполнителя, ₽/час ручная обработка ≈ {X} ₽ в месяц полученную сумму сравнивайте не с нулём: часть работы по приёмке останется людям И главное про деньги: не считайте стоимость нейросети, считайте себестоимость одной вашей операции. Пока вы не знаете эту цифру, вы не управляете процессом — как мы это считаем , разобрано отдельно, включая ночь, которая стоила минус сорок долларов из-за отсутствия лимита. Две ошибки, которые стоили мне месяцев Первая — искал более сильную модель вместо того, чтобы описать свои данные. Разница между моделями оказалась в пределах погрешности, разница от описания типов — двадцать шесть процентных пунктов точности. Как это выглядело в цифрах, разобрано в истории про распознавание документов . Вторая — строил стопроцентную автоматику, считая половинчатые режимы слабостью. Ошибка ровно наоборот, и обошлась она дороже первой: доверие команды восстанавливается медленнее, чем настраивается техника. Обе ошибки об одном: я решал техническую задачу там, где стояла управленческая. Это и есть главный риск внедрения — он не в модели. Внедрять самим или звать подрядчика Решение зависит не от бюджета, а от того, есть ли у вас человек из прошлого раздела. Своими силами реально чаще, чем принято думать: инструменты открыты, вход стоит десятки долларов, а основная работа — управленческая. Так начинали мы, и оглядываясь, считаю это правильным: мы разобрались в собственных процессах глубже, чем разобрался бы любой внешний исполнитель. Подрядчик нужен, когда процесс завязан на ваши системы и требуется разработка подключений. Но требуйте одного: правила и инструкции пишутся вместе с вашим человеком и остаются у вас в читаемом виде. Инструкции, а не код, — главный актив этого проекта. Уйдёт подрядчик, останутся правила — восстановите за недели. Наоборот — начнёте с нуля. И красный флаг при выборе: если вам называют срок в месяцы и сумму в миллионы за один процесс — либо продают платформу вместо контура, либо закладывают в смету собственное обучение за ваш счёт. Как понять, что внедрение ИИ состоялось Не по числу операций и не по аптайму. Три признака: Решения меняются. Из-за работы машины еженедельно случаются управленческие действия: разборы, правки процессов, изменённые скрипты. Две недели без единого решения — контур работает в стол. Старый способ отключён. Не «почти», не «остался на всякий случай». Отключён, и никто не просит вернуть. Себестоимость операции известна. Вы можете назвать её вслух, и она стабильна. Не можете — вы не управляете контуром, а спонсируете его. Что сделать на этой неделе Не искать подрядчика и не изучать рынок платформ. Три вещи за вечер. Первое. Выпишите процессы с потоком — те, что повторяются десятки раз в неделю. Отметьте, у каких из них есть проверяемое правило качества. Второе. По одному такому процессу посчитайте цену операции вручную. Калькулятор выше. Эта цифра решит, стоит ли вообще начинать. Третье. Назовите имя человека, который будет принимать работу машины. Если имени нет — не начинайте: вы точно повторите мой провал с семью тысячами оценок, из которых в решение превратилась одна. Дальше — механика: анатомия исполнителя , подключение к вашим системам , работа с данными . А пройти весь маршрут по шагам, с практикой на своих процессах, можно в бесплатном курсе — он бесплатный и идёт в Telegram. И если вы сейчас читаете это с мыслью «у нас всё то же самое, только хуже» — спокойно. Я потратил на это два года: подступался к очевидно нужной задаче, откладывал, возвращался, снова откладывал. Не потому что был занят, а потому что не понимал, с какой стороны браться. Когда наконец сел — первый работающий результат появился за недели. Дорого обошлось не внедрение, а ожидание. И последнее. Внедрение ИИ сегодня — не про технологический прорыв, а про обычную управленческую работу: выбрать участок, назначить ответственного, отключить старое вовремя. Компании, которые это поняли, обгоняют не потому, что у них лучше модели. У всех одинаковые модели. У них есть человек, который довёл дело до конца.

## Автоматизация бизнес-процессов: первым берут не тот процесс, где болит, а тот, с которым вы встанете
URL: https://davidgerstein.pro/blog/kak-vybrat-pervyy-process-dlya-avtomatizacii/
Дата: 2026-08-31
Направление: Операционное управление
Цифры: 4 вопроса теста, 6 недель на первый результат, 4-й месяц настройки у неправильного кандидата
Коротко: Автоматизация бизнес-процессов начинается не с самой громкой боли, а с процесса, где машина ошибается дёшево: из 15 процессов типового списка стартовыми годятся 3–4, вероятность попасть вслепую — 1 к 5. Тест из 4 вопросов: дёшево ли ошибается машина (1 случай из 20), опишут ли процесс 2 исполнителя одинаково, виден ли результат снаружи, есть ли хозяин. Два процесса для сравнения: оценка звонков идёт 4-й месяц и требует 10 чек-листов, мониторинг откликов заработал за 6 недель.

Цифры в разборе пересчитаны на условную компанию — механика, сроки и выводы реальные. Вы уже решили, что автоматизация бизнес-процессов вам нужна. Список процессов лежит перед вами, в нём 15 строк, и все пятнадцать выглядят достойными. Коммерческий директор тянет на продажи — там деньги. Операционный на документооборот — там боль. Вы смотрите на оба и понимаете, что 3 месяца можно потратить не туда, а второго захода команда вам не простит. Если вы выбираете первый процесс по тому, где сильнее болит, — вы почти наверняка выберете тот, который вас и похоронит. Я потратил на эту ошибку 2 года. Не 3 месяца — 2 года. Самой заметной болью у меня была расшифровка и оценка звонков: сотни разговоров в месяц, руководитель слушает выборочно 10–15, остальное — чёрный ящик. Я подступался к этой задаче снова и снова, потому что она болела громче всех. А взлетел совсем другой процесс — тот, о котором я вообще не думал как о приоритетном. С чего начинать автоматизацию бизнес-процессов Автоматизация бизнес-процессов начинается с того процесса, где машина ошибается дёшево, а не с того, где сильнее болит. Самый болезненный процесс сложен именно потому, что в нём много исключений: контур оценки звонков с 10 сценариями идёт 4-й месяц , а простой процесс с одним набором правил заработал за 6 недель . Тест из 4 вопросов: что будет, если машина ошибётся в 1 случае из 20; опишут ли процесс 2 исполнителя одинаково; виден ли результат за пределами отдела; есть ли конкретный хозяин. Проходить должны все четыре. Почему самый больной процесс — худший кандидат Он больной не случайно. Он больной потому, что сложный. В нём много исключений, много участников и много несогласованности, накопившейся годами. Именно поэтому его до сих пор никто не починил руками. Возьмите наш контроль качества звонков — тот самый, к которому я шёл 2 года. Он сейчас работает: разговоры выгружаются, расшифровываются, классифицируются по типу, оцениваются по чек-листу, результат попадает в кабинет руководителя. Красиво. А теперь честная сторона. Типов разговора оказалось не 2 и не 3 — понадобилось 10 разных чек-листов под разные сценарии. Настройка идёт четвёртый месяц и всё ещё требует доработок. Отдельная история — сама машина: на одном и том же разговоре 5 прогонов подряд дают 5 слегка разных оценок. Это не поломка, это свойство языковых моделей, и с ним приходится проектировать: усреднять, огрублять шкалу, держать человека на калибровке. Всё это — нормальная цена за хороший процесс. Но представьте, что это ваш первый проект. 4-й месяц, 10 чек-листов, оценки пляшут, а команда стоит рядом и делает выводы про всю затею целиком. Сроки при этом множатся, а не складываются — разобрал арифметику отдельно . Первый процесс отвечает не за экономию. Он отвечает за то, поверит ли вам компания на втором. Как выглядит полный маршрут от решения до эксплуатации — разобрал отдельно — маршрут на два-три месяца и три развилки, на которых всё ломается . Что взлетело вместо него Заработал скучный процесс, за который никто не голосовал. Менеджер по найму каждый день руками просматривала отклики на вакансии: заходила на портал, открывала резюме, фильтровала по критериям, вела учёт в голове и блокноте. Сделали так: агент раз в сутки сам ходит в портал через интеграцию, забирает новые отклики, раскладывает в таблицу — просмотры, клики, отказы, статус каждого резюме по критериям. Решения по кандидатам остались за человеком. Машина не выбирает людей — она приносит разложенное. 6 недель от разговора до работающего: 2 недели на описание правил отбора, 3 на сборку и проверку, 1 на приёмку. И главное — понятный результат, который видно снаружи: таблица есть, она пополняется сама, менеджер утром открывает её вместо 10 вкладок. Разница между двумя процессами не в технологии. Она в цене ошибки. Если агент неверно разметил 1 отклик из 20 — менеджер это увидит и поправит за 10 секунд. Если машина неверно оценила разговор менеджера, а вы на этой оценке строите разговор о премии, — вы разрушаете доверие к системе и к себе. Два процесса рядом: почему один взлетел, а другой идёт 4-й месяц Параметр Оценка звонков (шёл первым в моей голове) Мониторинг откликов (взлетел на самом деле) Срок до работающего результата 4 месяца и продолжается 6 недель Вариантов обработки 10 чек-листов под разные сценарии 1 набор критериев Цена одной ошибки машины Разговор о премии на кривой оценке Менеджер поправит за 10 секунд Разброс на повторных прогонах 5 прогонов — 5 разных оценок Разметка стабильна, спорное видно глазом Виден ли результат снаружи Только руководителю отдела Таблица, которую открывают каждое утро Кто хозяин Спорили 2 месяца Назначен в первый день Годится первым? Нет Да Обратите внимание: по величине боли первый выигрывает с разгромным счётом. По пригодности для старта — проигрывает по всем шести строкам. Как раскладываются 15 процессов из типового списка Когда мы прогоняли через тест списки процессов у себя и на разборах, картина получалась примерно одинаковая — и она объясняет, почему автоматизация бизнес-процессов так часто буксует на первом же проекте: выбор наугад почти всегда мимо. Годятся первыми — 20% Годятся, но не первыми — 47% Не годятся вообще: нет регламента или хозяина — 33% То есть из 15 строк вашего списка стартовых кандидатов — 3, максимум 4. Вероятность попасть в них вслепую — 1 к 5. Именно поэтому 20 минут на тест дешевле 3 месяцев на угадывание. Критерий, который стоит выше экономии Спросите не «сколько сэкономим», а «что будет, если она ошибётся в 1 случае из 20». Ответ «ничего страшного, человек поправит» — берём в первые. Ответ «клиент уйдёт, попадём на деньги, поссоримся с командой» — берём, но не первым. Тест из четырёх вопросов Выпишите 3 кандидата и прогоните каждого. Проходить нужно все 4 — 3 из 4 не считается. 1. Дёшево ли она ошибается? Разобрали выше. Добавлю одно: сюда же попадают процессы, где на один и тот же вход нужен строго один и тот же ответ. Машина по своей природе даёт разброс. Там, где разброс недопустим — расчёты, суммы, юридические формулировки, — либо не первый процесс, либо машина готовит, а решает человек. 2. Опишут ли его два исполнителя одинаково? Возьмите 2 человек, кто делает эту работу, и попросите порознь расписать шаги. Не вместе — порознь. Если описания разошлись — остановитесь. Вы автоматизируете не работу, а спор о работе, и машина зафиксирует в коде победу того, кто громче. Если разошлись — поздравляю, вы нашли не задачу для ИИ, а дыру в управлении , которая жила у вас и без всякого ИИ. Сначала регламент, потом машина: описать процесс до одной версии и найти в нём узкое место нужно раньше, чем что-то автоматизировать. Регламент, кстати, теперь пишется за вечер — с той же машиной, по расшифровке разговора с обоими исполнителями. Этому я учу отдельно, в курсе есть модуль ровно про это . 3. Виден ли результат снаружи? Результат должен быть заметен человеку за пределами отдела, без объяснений и презентаций. Таблица, которая пополняется сама. Отчёт, который приходит в 8 утра. Папка, где документы разложены. Внутренние улучшения — «стало удобнее», «меньше ручной работы» — не годятся для первого проекта. Не потому что они хуже, а потому что первый проект вы защищаете перед компанией, и защищать придётся тем, что видно. 4. Есть ли у него хозяин? Не исполнитель — хозяин. Человек, у которого спросят, когда сломается, и который считает этот процесс своим. Самый дорогой мой провал в этом году не имел отношения к технологиям. Рассылка встала на 4 недели. Разбирались — оказалось, менеджер не знала, что техническая часть вообще не её зона: она думала, что должна разобраться сама, не разобралась и молчала. Задача не сломалась. Она просто была ничья. Это самая частая причина, по которой проекты глохнут, — собрал их в разборе «Почему внедрение ИИ не работает» . Похожая история с дашбордом: собрали, запустили, красиво. Через 2 недели выяснилось, что в него никто не заходит, — потому что не назвали, кто по нему принимает решения. Три возражения, которые вы услышите от команды Как только вы назовёте выбранный процесс, начнётся торг. Он предсказуем, и лучше знать ответы заранее — иначе выбор поплывёт обратно к самому больному. «Это же мелочь, зачем на неё тратить силы» Скажет тот, кто голосовал за большой процесс. Ответ короткий: первый проект покупается не эффектом, а доверием. У вас в компании сейчас нет ни одного человека, кто своими глазами видел, что это работает. После первого — будет отдел. После второго — половина компании перестанет спорить и начнёт приносить свои задачи. Это и есть настоящая экономия первого проекта, и она не считается в часах. «Давайте сразу сделаем нормально, на весь объём» Самое опасное возражение, потому что звучит по-взрослому. Мы на этом обожглись: пытались вести разработку и внедрение одновременно — и остановились. Развернули иначе: сперва 40 случаев с ручной проверкой людьми, потом контролируемый сегмент, потом весь объём. Каждый шаг показывает, где машина врёт, пока цена ошибки ещё копеечная. На полном объёме та же ошибка стоит доверия ко всей системе. «У нас процесс сложный, у нас так не получится» Обычно это говорит человек, который боится, что автоматизация покажет, как процесс устроен на самом деле. И тут я на его стороне: она действительно покажет. Поэтому первый проект не должен быть местом, где кому-то станет неуютно. Берите процесс, где сотрудник получает не контроль, а разгрузку, — как менеджер по найму, которая перестала открывать 10 вкладок. Тогда он ваш союзник, а не саботажник. Если ни один кандидат не прошёл Значит, у вас нет процесса для старта — есть 3 слишком крупных. Дробите. Мы так и делали, когда упирались: сначала обучали на 40 случаях с ручной проверкой людьми, потом выпускали на контролируемый сегмент в 5 000, и только потом на весь объём. Скучно, зато на каждом шаге видно, где машина врёт, — и видно это на 40 случаях, а не на 5 000. Возьмите самый крупный процесс и отрежьте от него один слой: не «автоматизировать документооборот», а «собирать входящие документы в одну папку с разметкой типа». Этот кусок пройдёт тест. И сразу закладывайте в него три свойства из разбора «Автоматизация, которая требует надзора» — иначе получите процесс, за которым надо следить. Промпт: прогнать кандидатов через тест за один заход Тест можно пройти в голове, но в голове вы будете жалеть выбранный процесс. Машина не жалеет. Я отдаю ей описание кандидатов и прошу оценить по четырём критериям — на выходе получаю ранжирование и, что важнее, список того, чего я про процесс не знаю. Описание каждого кандидата — 5–7 строк своими словами: кто делает, как часто, что на входе, что на выходе, что бывает, когда ошибаются. Ответы модели проверяйте: она уверенно рассуждает о процессах, которых не видела, и это нормально — вам нужен не вердикт, а вопросы, которые она задаст. Отдельно попросите модель проверить пункт 2 жёстко: пусть найдёт в вашем описании места, где возможны два толкования. Обычно их два-три, и это ровно те места, где два ваших исполнителя разойдутся. Навык, которого у большинства нет Оценивать процесс по цене машинной ошибки — такой же базовый навык руководителя, как оценивать проект по сроку окупаемости. Пока вы его не освоили, вы выбираете вслепую: берёте то, что громче болит, и удивляетесь, почему через 6 месяцев тема закрыта фразой «мы пробовали». Первый процесс — это не самая тяжёлая штанга в зале. Это та, с которой вы точно встанете. Встать надо не один раз: первый проект оплачивает второй доверием, второй третий — деньгами. Все компании сейчас стоят на одной беговой дорожке, и разница между теми, кто побежит, и теми, кто останется, начинается с того, встали вы в первый раз или нет. Сядьте сегодня и выпишите 3 кандидата. Прогоните через 4 вопроса. Тот, что прошёл, — ваш. На это уйдёт 20 минут, а сэкономит 3 месяца.

## Специалист по внедрению ИИ: не ИТ-директор, не энтузиаст и не вы
URL: https://davidgerstein.pro/blog/kto-dolzhen-vesti-vnedrenie-ii/
Дата: 2026-08-31
Направление: Операционное управление
Цифры: −25,5 п.п. разрыв на единственной калибровке, 3 неделегируемые обязанности, 400 000 автоответов без дверей
Коротко: Специалист по внедрению ИИ внутри компании — это не отдельная вакансия, а владелец процесса: человек, которому результат нужен для собственной работы, а не ИТ-директор и не энтузиаст, собравший контур. У роли 3 обязанности, которые нельзя передать подрядчику: приёмка результата, калибровка машины против людей, отключение старого способа. Цена отсутствия хозяина в цифрах: сверка ИИ с людьми проведена 1 раз, разрыв −25,5 п.п., за 2 месяца он сжался до −5,5 п.п. — и этого никто не измерял. Второй пример: портал на 400 000 автоответов, где контент готов, а техническая часть месяцами не завершена.

Цифры пересчитаны на условную компанию — механика, сроки и выводы реальные. Контур собран. Процесс выбран правильно, подрядчик отработал, на демонстрации всё красиво. Остаётся мелочь — назначить внутри человека, который это поведёт. Вы перебираете: ИТ-директор? операционный? тот аналитик, который сам притащил вам нейросети и горит темой? И где-то на третьем круге ловите себя на мысли, что проще вести самому. Если на вопрос «кто у вас отвечает за это внедрение» вы называете должность, а не имя, — внедрения нет. Есть проект, который какое-то время будет выглядеть живым. У машины нет начальника по умолчанию. Пока вы не назначили человека, она работает на никого — и это состояние держится месяцами, потому что снаружи выглядит нормально: сервер жужжит, данные копятся, отчёты формируются. Кто такой специалист по внедрению ИИ Специалист по внедрению ИИ — это не вакансия на рынке, а роль внутри: владелец процесса, которому результат машины нужен для его собственных решений. Не ИТ-директор: он запустит контур, но не сможет судить о качестве результата, потому что не он читает эти документы и не он разговаривает с клиентами. Цена отсутствия хозяина измерима: сверку машины с людьми провели один раз , разрыв составил −25,5 п.п. , повторного замера не было. Два месяца никто не мог сказать, можно ли верить оценкам. Цифра, которая объясняет всё У нас работает контур оценки разговоров. Машина слушает поток и ставит оценки по чек-листу. Чтобы этим можно было пользоваться, машину надо сверять с людьми: берём выборку, оцениваем руками, смотрим расхождение. Такую сверку у нас провели 1 раз . 25 июня. Разрыв составил −25,5 процентных пункта : машина оказалась систематически строже людей. Вывод записали, правки в промпт наметили. Повторный замер не зафиксирован. Ни через месяц, ни через два. Дальше самое интересное. К концу августа разрыв сжался до −5,5 п.п. — то есть система пришла в норму сама, по ходу правок. И этого тоже никто не измерял. Мы узнали цифру только когда специально полезли проверять, что там происходит. Два месяца процесс жил вслепую. Не сломанный — просто без хозяина. Никто не мог сказать, можно ли верить оценкам сегодня: те, кто их читал, не знали про разрыв, а тот, кто знал про разрыв, не смотрел на оценки. Это тот же механизм, из-за которого внедрения не работают при исправной технике. Что тут важно Контур не упал и не выдал чушь. Он работал. Отсутствие хозяина проявляется не в поломке, а в том, что никто не может ответить на вопрос «этим сейчас можно пользоваться?». И пока ответа нет, результатами не пользуются — тихо, без объявления войны. Почему ИТ-директор — худший из очевидных вариантов Он кажется правильным ответом: технология же. И он действительно запустит. Проблема начинается на следующий день после запуска. Судить о качестве машинного результата может только тот, кто делал эту работу руками. ИТ-директор не читает ваши договоры, не слушает разговоры с клиентами, не разбирает отклики кандидатов. Он видит, что процесс отработал без ошибок. Отработал ли он правильно — не его компетенция и не его интерес. Живой пример из нашего периметра. Портал: собрано 400 000 вопросов с автоответами, сделан дизайн, контент готов. Техническая сборка не доведена месяцами. Формулировка, которой это описали на планёрке, лучше любого моего объяснения: «красивый дом, но дверей нету» . Все компоненты на месте, ответственный есть, а войти нельзя. Второй случай — мельче и потому показательнее. Автоматизация заполняла общую таблицу и затирала строки, которые сотрудники добавляли руками. Человек прямо сказал: я вношу строчку, а оно мне всё обновляет. Проблему обсудили, зафиксировали. Ответственного за исправление и срок не назначили. Она продолжила жить — и продолжала бы сколько угодно, потому что для существования проблемы хозяин не нужен, он нужен для её закрытия. Кого назначить специалистом по внедрению ИИ Владелец процесса. Руководитель, которому результат машины нужен для его собственных решений: начальник отдела продаж, если контур оценивает разговоры; операционный, если разбираются документы; тот, кто нанимает, если речь про отклики. Как выбрать сам процесс — разобрал отдельно ; здесь речь о том, кто его поведёт. Критерий простой: если машина начнёт врать, этот человек пострадает первым. Тогда у него есть личный мотив ловить враньё. У ИТ-директора такого мотива нет, у энтузиаста-аналитика — нет, у подрядчика — тем более нет. Кандидат Что сделает хорошо Где развалится Годится? ИТ-директор Запустит, подключит, обеспечит стабильность Не оценит качество результата — не его работа и не его боль Как исполнитель, не как ведущий Энтузиаст, который принёс ИИ Соберёт быстро и дёшево, будет гореть Ему интересна сборка, а не эксплуатация: через 2 месяца уйдёт в новую игрушку Нет Подрядчик Сделает контур и поддержит технически Не может принимать решения и отключать старый способ — это внутренняя власть Нет Собственник Продавит любое решение Не хватит времени на калибровку; станет узким местом, не заметив этого Только на 1-м процессе Владелец процесса Судит о качестве, принимает работу, отключает старое Нужны 2–4 часа в неделю и прикрытие от текучки Да Три обязанности, которые нельзя делегировать Всё остальное — сборку, поддержку, доработки, мониторинг — отдавайте кому угодно. Эти три остаются на человеке с именем. 1. Приёмка по понятному правилу Не «посмотрел, вроде нормально», а заранее записанное правило: что считается годным результатом. Без правила приёмка превращается в настроение, а настроение меняется, и подрядчик перестаёт понимать, что от него хотят. 2. Калибровка по расписанию Та самая сверка машины с людьми. Раз в месяц на старте, раз в квартал потом. Выборка, ручная оценка, сравнение, запись цифры. Двадцать минут работы, которые никто не делает, потому что они не горят. Именно эти сверки и определяют срок проекта — не сборка контура. Арифметика в разборе сроков: две-три недели до первого результата и два-три месяца до устойчивой пользы . Именно тут теряется больше всего. Наш разрыв в 25,5 пункта был известной величиной — про него знали, его записали. Не было человека, чья обязанность — замерить его снова через месяц. 3. Решение об отключении старого способа Самое политически тяжёлое. Пока живут обе схемы, команда работает по привычной, а компания платит за две. Отключить может только тот, у кого есть на это власть внутри отдела. Подрядчик не может, ИТ не может, вы — можете, но вас не будет рядом в нужный момент. Полный маршрут внедрения по неделям — с какого процесса начинать и когда отключать старый способ работы . Сборка контура — 15% усилий Приёмка и правила — 25% Калибровка и разбор расхождений — 35% Отключение старого и работа с людьми — 25% Так распределяются усилия на нашем контуре по факту первых месяцев. Обратите внимание на пропорцию: то, за что все переживают — сборка, — занимает седьмую часть. Остальное делает человек внутри, и подрядчик за него это не сделает ни за какие деньги. Теперь неприятная часть — про вас У нас проект по интеграции встал на месяцы. Причина не техническая: не могли назначить руководителя. Обсуждали, возвращались, снова обсуждали. Собственник понимал, что тратит собственное время на то, что должен решать не он, и всё равно не отпускал — опасался потерять контроль . Сроки горели, решение не принималось. Я видел эту схему у нескольких компаний и назову её прямо: вы не назначаете человека не потому, что некого. Вы не назначаете, потому что не готовы отдать контроль. Пока это не признано вслух, проект стоит, а вы уверены, что он идёт — потому что вы им регулярно занимаетесь. Проверка на себе занимает минуту. Ответьте: если вы уедете на 3 недели без связи, кто примет работу машины и кто заметит, что она поехала? Если ответ «никто» или «подождут до моего возвращения» — ведущего нет, есть вы в роли узкого места. Признак перегруза, который я слышал дословно: «я прям теряюсь от количества задач». Так звучит не лень и не слабость — так звучит отсутствие делегирования, доведённое до предела. Лечится оно назначением имени, а не удвоением собственных часов. Что делать с сопротивлением сотрудника Здесь я обязан сказать про свою ошибку. Долгое время я разговоры про «я не хочу с этим работать» решал давлением: надо, значит надо, разберёшься. Работало плохо. Перелом случился на одном разговоре. Сотрудница, объективно сильная — сделала анализ экономики, нашла проблемы, построила модели, — говорила о себе «я ничего не делаю». А дальше сформулировала настоящий страх: «боюсь, что мы потеряем живое общение, люди и жизненность — это главное» . Она боялась не машины. Она боялась перестать быть нужной и потерять то, за что любит свою работу. На это давление не действует — действует только конкретика: что именно останется за ней, что заберёт машина, и почему первое важнее второго. Плюс поддержка расписанием, а не лозунгом: короткая сессия на следующий день, потом чек-лист на неделю вперёд. Правильная раскладка ролей снимает половину страха сама. В нашем HR-контуре агент собирает отклики и раскладывает по критериям, а решения по кандидатам остаются за менеджером . Человек не потерял работу — он потерял её худшую часть. Это надо проговаривать вслух до запуска, а не после. Когда специалист по внедрению ИИ становится отдельной должностью Частый вопрос: не пора ли завести человека, который занимается только этим. Отвечаю по опыту: на первых двух-трёх контурах — нет. Это доп. нагрузка на владельца процесса, 2–4 часа в неделю, и её надо честно снять с него в другом месте, а не добавить сверху. Отдельная роль появляется, когда сходятся два признака. Первый: контуров больше пяти, и калибровка перестаёт помещаться в чужой календарь — она всегда проигрывает горящим задачам, потому что не горит сама. Второй: между контурами появляются связи, и кто-то должен держать картину целиком. У нас такой момент наступил на перегрузе, а не по плану. Формулировка была прямая — задач столько, что руководитель теряется в их количестве и раздаёт без внятного приоритета. Решением стало не «нанять ещё маркетолога», а вывести отдельного человека, который держит процессы и разгружает первое лицо. Это дорого, и на месте собственника я бы дотерпел до пятого контура — но дотерпеть надо осознанно, а не выяснить постфактум, что полгода всё стояло. И маленькое предупреждение про красивое название. Вакансия «специалист по внедрению ИИ» притягивает кандидатов, которые умеют рассказывать про ИИ. Вам нужен не рассказчик, а человек, который в состоянии сказать «эта оценка неверна, вот почему» — то есть знающий вашу работу изнутри. Такого проще вырастить, чем нанять. Как понять через месяц, что вы назначили правильно Три проверки, каждая занимает минуту. Первая. Спросите этого человека, какая сейчас цифра расхождения между машиной и людьми. Если он назовёт число и дату замера — роль работает. Если ответит «в целом нормально» — не работает, вы назначили номинально. Вторая. Посмотрите, к кому команда идёт с вопросами про контур. Если к подрядчику или к вам — ведущего не признали. Признание роли видно по маршруту вопросов, а не по приказу. Третья. Спросите, что уже отключено из старого способа. Ответ «ничего, пока параллельно» на втором месяце — тревожный: значит, человек боится принять решение, и надо разбираться, не хватает ему полномочий или уверенности. Второе лечится вашим публичным «я его поддержу», первое — вашим приказом. Промпт: собрать паспорт роли за один заход Самая частая отговорка — «не знаю, что именно ему поручить». Это решается за 15 минут: опишите процесс и попросите машину развести зоны. Ответ проверяйте — она склонна раздувать роль до отдельной должности, а вам нужны 2–4 часа в неделю на живом руководителе. Навык, которого нет ни в одной должностной инструкции Принимать работу машины — отдельный управленческий навык. Он не совпадает ни с одной существующей ролью: это не про технологии, не про аналитику и не про управление людьми. Это умение сказать, годится ли результат, по правилу, а не по ощущению, и поймать момент, когда машина начала врать. На рынке его не купить — нет ни специальности, ни диплома. Значит, придётся вырастить внутри, на первом же процессе, из человека, который у вас уже работает. Я на это трачу вечера с руководителями и собрал методику в курс , потому что объяснять одно и то же по десять раз оказалось дороже, чем один раз записать. Компании на беговой дорожке отличаются не моделями — модели у всех одинаковые. Отличаются тем, есть ли внутри человек, который умеет судить о работе машины. У кого он есть, тот прибавляет каждый месяц. У кого нет, у того контуры работают на никого, как наш разрыв в 25,5 пункта, о котором два месяца никто не знал. Назовите имя сегодня. Вслух, при команде, с тремя строками: что принимает, как часто сверяет, когда отключаем старое. Это разговор на 20 минут, и он определяет, будет у вас через полгода работающий контур или красивый дом без дверей.

## Внедрение ИИ в компании: считайте срок в циклах приёмки, а не в неделях
URL: https://davidgerstein.pro/blog/skolko-vremeni-zanimaet-vnedrenie-ii/
Дата: 2026-08-31
Направление: Операционное управление
Цифры: 2–3 недели техники против 2–4 месяцев внедрения, 5–8 циклов приёмки, 4-й месяц у контура с 10 сценариями
Коротко: Внедрение ИИ в компании технически укладывается в 2–3 недели, но до устойчивой пользы проходит 2–4 месяца, и разница почти целиком лежит в календаре руководителя. Считать проект надо в циклах приёмки: их всегда 5–8 независимо от процесса, а длина каждого зависит от того, за сколько дней вы посмотрели результат. Контур оценки звонков с 10 сценариями идёт 4-й месяц не из-за сложности кода, а потому что это 10 отдельных циклов калибровки. Мониторинг откликов с 1 набором критериев занял 6 недель. Главный пожиратель срока — формулировка «отправлено на доработку» без даты возврата.

Цифры пересчитаны на условную компанию — механика, сроки и выводы реальные. Вам надо назвать срок. Партнёру, совету, себе в план года. Вы спрашиваете подрядчика — он говорит «две недели». Спрашиваете знакомого, который проходил, — «полгода, и то не факт». Оба звучат уверенно, и вы понимаете, что один из них врёт, только не знаете который. Не врёт никто. Они отвечают на разные вопросы. Срок внедрения на 80% состоит из вашего календаря, а не из работы подрядчика. Поэтому вопрос «сколько это займёт» вы задаёте не тому человеку. Сколько времени занимает внедрение ИИ в компании 2–3 недели на сборку работающего контура и 2–4 месяца до устойчивой пользы. Технической работы в этом сроке меньше четверти — остальное занимают циклы приёмки и калибровки. Считать надо в циклах: их всегда 5–8 на процесс, а длина одного зависит только от того, за сколько дней руководитель посмотрел результат. При ответе в тот же день шесть циклов проходят за 3 недели, при ответе раз в неделю — за 3 месяца. Что занимает 2 недели, а что — 4 месяца Собрать работающий контур — 2–3 недели. Это правда, и это не маркетинг: подключение к источнику данных, промпт, обработка, выгрузка результата. Через 2 недели у вас на руках штука, которая берёт реальные данные и выдаёт реальный результат. Дальше начинается то, о чём в коммерческих предложениях не пишут. Результат надо посмотреть. Сравнить с тем, как это делает человек. Найти расхождения, понять их причину, поправить правило, прогнать снова. И так по кругу, пока результату можно будет верить без проверки. Вот здесь и живут ваши месяцы. Не в коде — в кругах. Техническая сборка — 22% срока Циклы приёмки и калибровки — 48% Отключение старого способа и работа с людьми — 30% Считайте в циклах, а не в неделях Главная мысль этой статьи одна: проект меряется числом циклов приёмки, а не календарным временем. Циклов всегда примерно одинаково — 5–8 на процесс, и это число почти не зависит от вас. Первый круг показывает грубые ошибки. Второй — что правило сформулировано неоднозначно. Третий — редкие случаи, о которых никто не вспомнил. Дальше идёт шлифовка. Меньше пяти не бывает: если вам кажется, что хватило двух, значит вы не проверяли, а посмотрели. А вот длина одного цикла зависит целиком от вас. Подрядчик отдал результат в понедельник. Вы посмотрели в пятницу через неделю. Цикл — 12 дней. Умножаем на 6 кругов — три месяца, из которых работы было десять дней. Тот же проект при вашем ответе за сутки: цикл 3 дня, шесть кругов — три недели. Ваша скорость ответа Длина цикла 6 циклов Что вы скажете в конце В тот же день 2–3 дня 2–3 недели «Оказалось быстро» За 2–3 дня 5 дней 1,5 месяца «Нормальный темп» Раз в неделю 10–12 дней 3 месяца «Затянулось» Когда вспомню 3–4 недели 6 месяцев «Не взлетело» Обратите внимание: работа подрядчика во всех четырёх строках одинаковая. Меняется только ваша строка календаря — и итог отличается в 8 раз. Два наших контура и почему они разошлись в разы Мониторинг откликов на вакансии: 6 недель от разговора до работающего. Один набор критериев отбора, один человек принимает результат, критерии описаны за пару вечеров. Оценка разговоров: 4-й месяц и продолжается. И вот честная причина — не сложность кода. Типов разговора оказалось не два: понадобилось 10 разных чек-листов под разные сценарии. Каждый чек-лист — это отдельный цикл калибровки со своей выборкой, своим разбором расхождений, своей правкой правил. Десять сценариев — это десять очередей в один и тот же чужой календарь. Умножьте: 10 сценариев × 5 циклов × неделя ожидания. Получите ровно тот срок, который мы и наблюдаем. Это, кстати, ещё один довод не брать самый больной процесс первым : сложность процесса умножается на срок, а не складывается с ним. Правило прикидки Срок ≈ (число сценариев в процессе) × (5–8 циклов) × (ваша скорость ответа в днях). Прикиньте по своему процессу до старта — и вы либо перестанете удивляться срокам, либо сократите число сценариев на входе. Второе, кстати, обычно правильнее. Самая дорогая фраза в вашей компании Я вытащил из разборов за это лето все места, где что-то встало надолго, и увидел одну повторяющуюся конструкцию. Она звучит безобидно: «отправлено на доработку». Без даты возврата. Концепция мероприятия — отправлена на доработку, срок не назван, слот не забронирован. Тексты вакансий — обсудили половину, вторую не успели, дата не поставлена. Ошибка в таблице, которая затирала ручные строки: проблему нашли, зафиксировали, ответственного и срок не назначили. Рассылка встала на 4 недели, потому что человек не знал, что техчасть — не его зона, и молчал. Ни одна из этих задач не была отменена. Все они формально «в работе». Работа при этом не идёт, и узнаёте вы об этом через месяц, случайно. Во внедрении эта фраза стоит дороже всего, потому что она попадает точно в цикл приёмки — в то самое место, где и живут ваши месяцы. Введите правило: любая передача результата сопровождается датой, когда его посмотрят. Не «на неделе», а числом. Это одно правило сжимает срок проекта вдвое, и оно ничего не стоит. Реалистичный график внедрения ИИ в компании: что и когда Так выглядит нормальный ход для одного процесса с одним-двумя сценариями. Не идеальный — нормальный, с учётом того, что у вас есть основная работа. Период Что происходит Ваше время Признак, что идёте по графику Неделя 1 Описание правил: что считается годным результатом 2–3 часа Правило записано так, что по нему может судить другой человек Недели 2–3 Сборка контура, первые прогоны на реальных данных 1 час Есть результат на ваших данных, пусть кривой Недели 4–7 Циклы калибровки: сверка с людьми, разбор расхождений, правка правил 40 мин в неделю, стабильно Расхождение с людьми сокращается от цикла к циклу и записывается цифрой Недели 8–10 Теневой режим: машина работает параллельно с людьми, решения ещё за людьми 30 мин в неделю Сюрпризов больше нет, расхождения только в редких случаях Недели 10–12 Отключение старого способа Разговоры с командой Никто не ведёт параллельную ручную копию «на всякий случай» Итого — 2–3 месяца до состояния, когда процессом пользуются не из-под палки. Если вам обещают тот же результат за 3 недели, спросите, в какую неделю встроена калибровка. Ответа обычно нет. Где я сам потерял больше всего Не на плохом подрядчике и не на сложной технологии. На том, что не начинал. Задача с расшифровкой и оценкой разговоров висела у меня 2 года . Не два месяца — два года. Всё это время она была очевидно нужной, очевидно окупаемой и очевидно решаемой. Я к ней подступался, откладывал, возвращался. Когда наконец сел — первый работающий результат появился за недели. Два года ожидания против нескольких недель работы. Вот настоящая арифметика сроков внедрения, и она не про подрядчиков. Второй урок — из истории с сайтом. Мы собрали 12 типов страниц скриптом, посмотрели, увидели ошибки в оформлении и уже собрались доводить до идеала перед показом. Развернули иначе: взяли одну утверждённую страницу за эталон и приняли принцип — запускать с текущим качеством и проверять на реальных пользователях, а не полировать до релиза. С внедрением ИИ то же самое, только жёстче: пока машина не поработала на ваших настоящих данных, вы не знаете о ней ничего. Все ваши представления о том, где она ошибётся, — фантазии, и проверяются они за один прогон. Общий маршрут внедрения по неделям — в разборе маршрута по неделям: с какого процесса начинать и когда отключать старый способ . Как сжать срок вдвое, ничего не доплачивая Поставьте приёмку в календарь заранее Не «посмотрю, когда пришлют», а фиксированный слот: 40 минут раз в неделю на весь период внедрения. Он должен стоять до того, как проект начался, иначе будет проигрывать всему горящему — калибровка никогда не горит сама, в этом её главная беда. Режьте число сценариев на входе Раз срок умножается на количество сценариев, самый быстрый способ сократить его — начать с одного. Не «оценивать все типы разговоров», а один самый частый тип. Остальные добавляются потом, уже на отлаженной механике, и идут в разы быстрее первого. Дробите обучение машины Мы пришли к схеме: сперва 40 случаев с ручной проверкой людьми, затем контролируемый сегмент в 5 000 , и только потом весь объём. Кажется, что это удлиняет — на деле сокращает: ошибка, найденная на 40 случаях, стоит вечер, та же ошибка на полном объёме стоит доверия команды и месяца на его восстановление. Назначьте того, кто отвечает за скорость У циклов должен быть хозяин — человек, который следит, чтобы результат не лежал непосмотренным. Обычно это владелец процесса, он же специалист по внедрению ИИ , и у него на это должно быть выделено время, а не «в свободные минуты». Что происходит после «внедрили» Есть срок, о котором не спрашивают вообще, а он самый длинный: сколько живёт внедрённое. Ответ неприятный — ровно столько, сколько за ним смотрят. У нашего контура оценки разговоров сверку с людьми провели один раз , 25 июня. Разрыв составил −25,5 п.п. : машина оказалась строже людей. Повторный замер не зафиксирован ни через месяц, ни через два. К концу августа разрыв сжался до −5,5 п.п. — сам, по ходу правок, и этого тоже никто не измерял. Два месяца система работала вслепую. Формально проект был «внедрён» ещё весной. Фактически всё это время нельзя было ответить на простой вопрос: можно ли сегодня верить её оценкам. Поэтому в график добавляйте строку, которой нет ни в одном коммерческом предложении: калибровка раз в квартал, бессрочно. Двадцать минут работы, которые определяют, останется ваш контур рабочим инструментом или превратится в декорацию, о которой все помнят, что она есть, и никто не пользуется. Три ситуации, когда сроки поплывут гарантированно Их видно заранее, и лучше их назвать до старта, чем объяснять потом. Правила процесса не записаны. Если исполнители описывают работу по-разному, вы потратите первые 2–3 цикла не на калибровку машины, а на выяснение, как вообще должно быть. Это нормальная работа, но её надо считать отдельно и делать до сборки контура, а не во время. Приёмщик не тот человек. Когда результат принимает тот, кто не делает эту работу руками, циклы идут вхолостую: он не видит ошибок, которые видит практик, и они всплывают на третьем месяце, когда всё уже собрано. Возврат к правильному приёмщику стоит половины проекта. Старый способ никто не отключает. Пока обе схемы живут параллельно, у проекта нет конца — он бесконечно «дорабатывается». Дата отключения ставится в план на старте, вместе с датой запуска, иначе не наступает никогда. Промпт: посчитать срок по своему процессу Прикидка в голове всегда оптимистична — в ней вы отвечаете мгновенно. Отдайте расчёт машине и попросите быть пессимистом там, где данных нет. Дальше сверьте её число со своим ощущением: разница между ними и есть ваш личный коэффициент оптимизма, полезно знать. Навык, который здесь тренируется Считать проект в циклах приёмки, а не в неделях, — базовый навык для всего, что делается итерациями, а итерациями сейчас делается почти всё. Кто считает в неделях, тот всегда опаздывает и всегда искренне удивляется. Кто считает в циклах, тот заранее видит, что шесть кругов при его загрузке — это три месяца, и либо принимает это, либо меняет свою загрузку. Сжать цикл приёмки — отдельная работа, и она про правила, а не про скорость чтения. Этому я учу в курсе : как записать правило приёмки так, чтобы проверка занимала 10 минут вместо часа. Все компании сейчас на одной беговой дорожке, и обгоняют не те, у кого быстрее подрядчик. Обгоняют те, у кого короче цикл: посмотрел, сказал, поправили, посмотрел снова. Внедрение всегда идёт со скоростью самого медленного участника, и почти всегда самый медленный — тот, кто спрашивает про сроки. Откройте календарь и поставьте 40 минут в неделю на приёмку — на ближайшие три месяца, повторяющимся событием. Это займёт минуту и сократит ваш следующий проект вдвое.

## ИИ-агенты для бизнеса: пять элементов рабочего агента и три способа его угробить
URL: https://davidgerstein.pro/blog/ii-agenty-dlya-biznesa/
Дата: 2026-08-29
Направление: Операционное управление
Цифры: 5 элементов анатомии · 7139 операций за ~$300/мес · ночь без стоп-крана = −$40
Коротко: Агент отличается от чата тем, что получает не вопрос, а цель — и сам планирует шаги. Рабочий агент собирается из пяти элементов: цель с критерием приёмки, инструменты с минимальными правами, границы, бюджет со стоп-краном, точка приёмки человеком. Модель в этом списке отсутствует: её покупают, а строят как раз то, что перечислено, и это на 80% управленческая работа. Агент оценки звонков в компании на 40 человек разобран по всем пяти элементам — включая границы, каждая из которых появилась после конкретного случая, и провал управленческой петли, который свёл его пользу почти к нулю.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. «ИИ-агенты» сейчас продают как новую магию: агент сам ведёт клиента, сам закрывает сделки, сам работает вместо отдела. Если вы это читали и подумали «звучит слишком хорошо» — правильно подумали. Но и обратное неверно: агенты работают, у нас их три, и они делают то, что раньше не делал никто. Разница между этими двумя картинами — не в модели и не в бюджете. Она в пяти скучных вещах, которых нет ни в одном рекламном ролике. Про них и поговорим — на разборе агента, который третий месяц крутится у нас в проде. Что такое ИИ-агенты для бизнеса и когда они работают ИИ-агент — это модель, которой выданы цель, инструменты и границы, чтобы делать многошаговую работу без человека на каждом шаге. От чат-бота отличается входом: боту дают реплику, агенту — цель, и шаги он планирует сам. Рабочий агент собирается из пяти элементов: цель с критерием приёмки, инструменты с минимальными правами, явный список границ, бюджет со стоп-краном и человек на приёмке. Модели в этом списке нет — её покупают, а строят как раз эти пять. Агент оценки звонков в отделе продаж на восемь менеджеров сделал 7 139 оценок примерно за $300 в месяц и поднял охват с 25% до 100% потока разговоров. Работают агенты там, где есть поток однотипной работы, формализуемое правило оценки и человек, которому результат нужен регулярно. Нет хотя бы одного признака — задача пока не для агента. Чем агент отличается от чата — на одной задаче Возьмём задачу: оценить звонок менеджера по чек-листу. В чате это делаете вы: открыли транскрипт, вставили, попросили оценить, прочитали. Двадцать звонков — двадцать ручных заходов, и через неделю вы это бросите, потому что у директора есть занятия поинтереснее. Агент делает иначе. Раз в час сам забирает новые записи, определяет тип разговора, выбирает под него чек-лист, оценивает, пишет результат в таблицу, раз в день собирает сводку по менеджерам. Человек появляется дважды: когда задал правила и когда смотрит сводку. Формально разница с чатом — кто нажимает кнопки. По сути — принципиальная: агенту передают не задачу, а процесс , и вместе с ним ответственность за промежуточные решения. Какой чек-лист выбрать. Что делать с обрывком записи. Когда остановиться. Именно поэтому агент без правил опасен ровно настолько, насколько полезен агент с правилами. Пять элементов. Уберите любой — получите инцидент За три месяца эксплуатации я пришёл к тому, что рабочий агент собирается из пяти вещей. Это не теория, каждая строчка оплачена. Элемент Что это Что будет без него 1. Цель + критерий приёмки Что должно получиться и признак, по которому результат принят Агент «работает», результат никому не нужен 2. Инструменты и права Что читает, куда пишет — по минимуму Доступ «на всякий случай» = дыра в безопасности 3. Границы Явный список запретов Машина услужливо сделает то, что вы забыли запретить 4. Бюджет Лимит операций и денег, стоп-кран Ошибка в цикле съедает месячный бюджет за ночь 5. Приёмка Человек и точка, где он смотрит результат Ошибки копятся молча до первого скандала Заметили, чего в списке нет? Модели. Она важна, но её покупают, а не строят, — что именно покупается и на что оно способно, разложено по шести ступеням: от текста и таблиц до подключения к вашим системам . Строят ровно то, что в таблице, и это на восемьдесят процентов управленческая работа, а не программистская. Ту же самую работу вы делаете, вводя в должность нового сотрудника, — просто с людьми она делается на автопилоте, а с машиной приходится проговаривать вслух. Разбор: наш агент по пяти элементам Цель. «Каждый звонок отдела продаж оценён по чек-листу своего типа в течение часа после появления записи». Критерий приёмки закладывался не на глаз: месяц калибровки на 66 звонках с параллельной ручной оценкой, расхождения разбирались по одному — пока не стало ясно, каким пунктам можно доверять сразу, а какие держать под выборочной проверкой. Инструменты и права. Читает записи и транскрипты, пишет в свою таблицу оценок. В CRM не пишет ничего. Это решение, а не ограничение технологии: таблица — черновик, который человек может целиком выбросить, CRM — боевая система, где ошибка расползается по отчётам. Границы. Выглядят прозаично, но каждая появилась после конкретного случая. Не оценивать звонок по обрывку транскрипта — после того как выяснилось, что оборванный на середине разговор машина уверенно оценивает как полный. Не пересчитывать уже принятые оценки задним числом. Не делать выводов о менеджере — только о звонке: обобщения делает руководитель, а не машина. Бюджет. Лимит вызовов в час и денежный потолок в день. Звучит перестраховкой ровно до первого случая: у нас есть разбор ночи, которая стоила минус $40 — зацикленный процесс жёг деньги до утра, и остановил его лимит, а не человек. У сотрудника есть здравый смысл и усталость. У машины нет ни того, ни другого — бюджет заменяет ей и то и другое. Приёмка. Ежедневная сводка руководителю отдела, выборочная сверка с прослушиванием, ежемесячный разбор расхождений. И здесь мой самый неприятный урок, который я расскажу отдельно. Как я угробил идеального агента Технически контур работал безупречно: 7 139 оценок, около $300 в месяц, аптайм месяцами . Охват вырос с четверти потока до ста процентов. Кейс, который не стыдно показывать. А теперь цифра, которую я публикую как прививку: из этих тысяч оценок в управленческое решение — разбор с менеджером, правку скрипта, хотя бы содержательный отзыв — превратилась одна . Одна. Агент исправно выдавал продукт, который никто не превращал в управление. Знаете, что обиднее всего? Все данные для решений лежали в таблице — открывай и разбирай. Не открывали. Это моя недоработка, не машины. Я построил образцового исполнителя и забыл, что у исполнителя должен быть руководитель. Технически — зелёное, управленчески — ноль. И если вы сейчас думаете «ну у меня-то так не будет» — я думал так же, и у меня были все цифры перед глазами. Поэтому единственная метрика, по которой стоит судить агента, — не количество операций, а количество решений, изменившихся из-за его работы . Сводка, по которой неделю не принято ни одного решения, — сигнал тревоги уровня «упал сервер». И назову вслух то, чего мне самому не хватило. Агент требует от директора отдельного умения: регулярно снимать урожай с машины — открывать то, что она произвела, и доводить до решения. Это такой же управленческий навык, как разбор отчётов или планёрка, и держится он на том же — на расписании, а не на энтузиазме. У меня он появился только после этого провала: до него я считал, что достаточно построить контур, а дальше цифры сами кого-нибудь убедят. Не убеждают. Убеждает человек, который в четверг в 10:00 открывает таблицу. Должностная инструкция агента Всё описанное сводится в один документ — системную постановку. Вот каркас; это не наш боевой текст, но структура ровно та же: Сравните с должностной инструкцией контролёра качества — совпадение почти дословное. Это не случайность: агент и есть исполнитель на узкой роли. И отсюда практический вывод, который экономит месяцы: компании с внятными регламентами собирают агентов в разы быстрее. У них инструкция уже написана — осталось перевести её в постановку. Если у вас регламентов нет, попытка собрать агента станет их первой версией. Неприятно, но полезно. Сколько это стоит вам Три числа для масштаба — прикиньте на свой поток. Себестоимость одной оценки — центы: месяц работы на 100% потока звонков обходится примерно в $300. Ручной аналог — контролёр, успевающий за полный рабочий день разобрать четверть потока. И третье, о котором забывают: стоимость надзора — калибровки, разборы, обновление чек-листов — это часы руководителя каждый месяц, и они не бесплатны. Автоматизация, которая требует надзора, — это вторая работа : меньше первой, но в ноль не сворачивается. Контролёр, полный день ~25% потока Агент, ~$300/мес 100% потока Про цену разработки. Узкий агент на готовой модели — дни или недели: код небольшой, дорога управленческая часть. Если подрядчик оценивает «агента» в месяцы и миллионы — либо это платформа, а не агент, либо вам продают то, о чём стоит прочитать разбор про умирающие внедрения . Три способа угробить агента Дальше — три сценария, в которых вы почти наверняка окажетесь, если пойдёте по этому пути. Знать их заранее дешевле, чем узнать на практике. Агент-максималист. Первая версия пытается делать всё: оценивать, обобщать по менеджерам, советовать увольнения. На демо выглядит эффектно, в эксплуатации разваливается — приёмку такого объёма никто не тянет. Лечится сужением: один процесс, один результат, один принимающий. Агент без стоп-крана. Цикл, ретраи, «ещё одна попытка» — и утренний счёт на месячный бюджет. Лечится лимитами, причём лимит должен останавливать, а не ставить в очередь. Агент-сирота. Технически жив, но принимающий человек сменил приоритеты, и результаты копятся в таблице, которую не открывают. Самый коварный: снаружи всё зелёное. Это ровно мой случай, описанный выше. Где ломается Общий корень всех трёх — отношение к агенту как к программе, а не как к исполнителю. Программу написал и забыл; исполнителя вводят в должность, ограничивают в правах, дают бюджет и спрашивают результат. Как только команда начинает относиться к агенту по-сотруднически, максималисты и сироты исчезают сами: появляются те же механизмы, что для людей — роль, руководитель, отчётность. Жизненный цикл: два-три месяца до пользы Если вы решитесь, вот что вас ждёт по календарю. У агента, дожившего до пользы, путь всегда один и тот же, и попытки перепрыгнуть этап возвращают вас на него же, только дороже. Неделя-две: ручной прогон. Процесс гоняется в чате руками, на реальных данных. Здесь выясняется, какие правила вы забыли сформулировать — у нас на этом этапе родилась половина границ, включая правило про оборванные транскрипты. В кабинете такое не придумывается. Неделя-две: теневой режим. Агент работает автоматически, результат никуда не идёт — только сравнивается с ручным. Это этап калибровки, он и отвечает на вопрос «можно ли доверять» цифрой, а не ощущением. Месяц: эксплуатация с плотной приёмкой. Результат используется, человек смотрит всё. Дорого по времени и намеренно: здесь всплывают редкие случаи, которых не было в калибровке. Дальше: рабочий режим. Приёмка сужается до выборочной и до пометок самого агента. Полностью не исчезает никогда. Где ИИ-агенты для бизнеса оправдываются уже сегодня Чтобы приземлить: контроль качества — оценка звонков, писем, чатов по чек-листам; первичная обработка входящего — разбор заявок, классификация, черновик ответа, маршрутизация, у нас это разобрано на потоке заявок ; документы — определение типа, извлечение полей, сверка комплектности, 79 типов с точностью 85% ; отчётность — ежедневные сводки с пометкой отклонений; протоколы — расшифровка совещаний в решения и задачи. Что объединяет эти случаи: везде есть поток однотипной работы, формализуемое правило оценки и человек, которому результат нужен регулярно. Проверьте свою задачу по этим трём признакам. Нет хотя бы одного — она пока не для агента, и это нормальный ответ, а не приговор. И предостережение к подборкам «лучших ИИ-агентов», заполонившим интернет: агента не выбирают из каталога — его собирают под процесс. Готовый «агент-продажник из топ-10» без ваших регламентов остаётся чат-ботом с амбициями. По той же причине осторожнее с модой на локальные агенты на собственном железе: локальность решает вопрос, где живут данные, но не отменяет ни одного из пяти элементов. Ваш первый агент — на этой неделе Начинайте с читающего: он берёт данные и готовит черновик. Испортить может только черновик, поэтому цена ошибки нулевая, а все пять элементов отрабатываются по-настоящему. Кандидаты почти в любой компании одинаковы: ежедневная сводка по продажам из CRM, еженедельный разбор новых договоров, протоколы планёрок — как у нас, с экономией порядка 70 часов в месяц на отдел (оценка) . Ориентир по срокам и деньгам: неделя ручных прогонов, неделя-две теневого режима, первый месяц эксплуатации с плотной приёмкой. Бюджет пилота через API — десятки долларов. Дорогим будет только ваше внимание, и это правильные расходы: именно они превращают игрушку в инструмент. Что сделать сегодня: выберите процесс с потоком, напишите для него четыре строчки — цель, две границы, кто принимает. Если написать не получилось — вы нашли не проблему с ИИ, а дыру в собственном процессе, и это лучшее, что могло случиться с вами за неделю. Как подключить такого исполнителя к вашим системам — в разборе про MCP , а если хочется пройти путь по порядку и с практикой — у меня есть бесплатный курс , там всё разложено по шагам.

## Анализ данных компании через ИИ: срезы, аномалии, формулы Excel — и границы доверия
URL: https://davidgerstein.pro/blog/ii-analiz-tablic-i-dannyh/
Дата: 2026-08-29
Направление: Операционное управление
Цифры: 4 класса задач на выгрузках · логика расчёта обязательна в каждой постановке · аномалии дат ловились именно так
Коротко: Анализ данных компании силами ИИ — это не «загрузил и получил инсайты»: на выгрузке в 1 200 строк за полгода Claude сильнее всего в 4 классах задач с выгрузками — срезы и динамика (конверсия по месяцам, структура выручки), поиск аномалий (ошибки ввода, сдвиги дат, дубли), формулы Excel и Google Sheets по описанию на русском, и объяснение чужих расчётов. Обязательное правило из практики: в каждой постановке требовать показать логику расчёта, а не только ответ — это одна строка, которая делает результат проверяемым. Данные перед загрузкой обезличиваются; выводы сверяются с источником так же, как отчёт живого аналитика.

Суммы и примеры пересчитаны на условную компанию — пропорции, механика и выводы реальные. Ответьте себе честно: когда вы последний раз задавали своим данным вопрос, ответа на который не было в готовом отчёте? Не «сколько продали», а «почему у М8 конверсия вдвое ниже — он плохо работает или ему валятся худшие лиды?». Если вы не вспоминаете такого случая за последний месяц — диагноз простой: решения у вас принимаются на ощущениях, а данные лежат мёртвым грузом. И стоят они ровно столько, сколько стоят ошибки, которых можно было избежать. Если давно или никогда — дело не в лени. Дело в том, что раньше между вопросом и ответом стоял аналитик, которого у вас нет. Теперь не стоит. И это, пожалуй, самая недооценённая штука во всей теме: про тексты знают все, про данные — почти никто. Что умеет ИИ в анализе данных компании Анализ данных компании через ИИ — это работа с обычной выгрузкой: вы отдаёте машине CSV из CRM или учётной системы и задаёте вопрос словами, по-русски. На выгрузке сделок за полгода (~1 200 строк) машина уверенно закрывает четыре класса задач: срезы и динамику, поиск аномалий, формулы Excel и Google Sheets по описанию, объяснение чужих расчётов. Цикл «выгрузка → постановка → проверка логики → контрольная сверка» занимает 10–20 минут на вопрос (оценка) — порядка 5–8 часов управленческого времени в месяц, которые раньше уходили на сводные таблицы или на «спрошу потом». Обязательное условие ровно одно: в каждой постановке требовать показать логику расчёта, иначе красивый ответ нечем проверить. Почему это важнее, чем кажется Смотрите, в чём перекос. У руководителя среднего бизнеса данных больше, чем аналитики: CRM пишет каждую сделку, учёт — каждый платёж, телефония — каждый звонок. Аналитика при этом чаще всего нет — есть таблицы, которые никто не открывает, и вопросы, которые некому задать. Разрыв закрывался двумя способами: нанимать (долго и дорого) или не спрашивать (бесплатно и грустно). Появился третий: выгрузка плюс машина, отвечающая на вопросы к данным по-русски. Он не отменяет аналитика на сложных задачах — он закрывает пустоту там, где аналитика не было и не будет. По нашей практике, регулярное «спрашивание данных» меняет и сами совещания: спор мнений заметно чаще упирается в предложение «давайте спросим выгрузку» — а это культурный сдвиг, который стоит дороже сэкономленных часов. Четыре класса задач, которые машина делает на выгрузках Класс Примеры вопросов Что важно в постановке Срезы и динамика Конверсия по месяцам; структура выручки; сравнение менеджеров Точные определения: что считаем сделкой, что периодом Поиск аномалий Ошибки ввода; дубли; сдвиги дат; выбросы сумм Просить не «найди странное», а проверить конкретные гипотезы Формулы и расчёты Формула Excel/Sheets по описанию; проверка чужой формулы Описать словами, что должно получиться, с примером Объяснение данных Что значит эта колонка; почему отчёты расходятся Дать обе версии данных, а не пересказ по памяти Общий принцип для всех четырёх: машина берёт вычислительную и черновую часть, определения и приёмка остаются за вами. Выгрузки — только один из жанров, где это работает: тот же принцип на текстах, документах и подключении к вашим системам . Дальше — три разобранных примера с постановками, которые можно скопировать и переделать под свои данные; в каждом обратите внимание не на «магию», а на то, сколько в постановке управленческих решений — что считать, что исключить, чему не верить. Пример 1: срез по воронке из сырой выгрузки Ситуация, в которой вы наверняка бывали. Исходные данные условной компании: выгрузка сделок за полгода, ~1 200 строк, колонки «дата создания», «стадия», «сумма», «менеджер», «источник». Вопрос владельца: где именно проседает воронка и у кого. Здесь три приёма, которые отличают вашу рабочую постановку от бесполезного «проанализируй таблицу». Первый — правила счёта прописаны явно : что исключаем, к какому месяцу относим. Без них машина примет разумные, но свои решения, и цифра разойдётся с вашей сводной — не потому, что кто-то ошибся, а потому, что считали разное; мы разбирали этот эффект в истории про «CRM врёт» , где три способа счёта давали три разных числа из одних данных. Второй — требование логики к каждой цифре. Третий — разрешение сказать «не могу» : без него машина услужливо посчитает даже то, что считать нельзя. Пример 2: поиск аномалий, который окупил месяц подписки Аномалии — класс, где машина сильна по-настоящему: у неё нет привычки к «так всегда было». Реальный тип находки из нашей практики — даты в CRM, тихо сдвинутые задним числом : доля лидов месяца меняла дату создания, и отчёты расходились в зависимости от дня выгрузки. Поймано именно сравнением двух выгрузок машиной. Обратите внимание на последнюю строку: гипотезы о причинах здесь запрещены сознательно. Причины — работа руководителя с админом системы; смешивание фактов с гипотезами в одном ответе — типичный способ получить убедительный, но неверный вывод. Пример 3: сравнение менеджеров без обид Третий частый запрос — сравнить людей. Здесь машина полезна не скоростью, а дисциплиной: она сравнивает по заявленным метрикам и не подмешивает впечатлений. В условной компании из восьми менеджеров срез по оплаченным сделкам за квартал выглядел так (оценка): Менеджер М1 31% Менеджер М2 25% Медиана отдела 20% Менеджер М8 12% Ценность не в самой картинке — её нарисует любая CRM. Ценность в вопросах вторым шагом: «у М8 низкая доля — проверь, отличается ли структура его сделок по источникам и суммам от медианных». Часто «слабый менеджер» оказывается менеджером, на которого валятся заявки худшего качества, — и это меняет решение с «ругать» на «чинить распределение». Машина делает такие проверки за минуты, и именно они защищают от управленческих выводов по одной цифре — мы писали об этом в разборе про конверсию и менеджеров . Большие выгрузки: как не утопить машину Практические пределы существуют: выгрузку на сотни тысяч строк со всеми колонками загружать не стоит — и не нужно. Рабочие приёмы: сузить период (квартал вместо трёх лет), оставить только участвующие в вопросе колонки, а для по-настоящему больших данных — попросить машину сначала спроектировать агрегацию («какими срезами мне выгрузить это из системы, чтобы ответить на вопрос X»), сделать агрегированную выгрузку и анализировать её. Парадокс, знакомый любому аналитику: сужение данных под вопрос почти всегда улучшает ответ, потому что заставляет сформулировать вопрос. Формулы по-русски: маленькая экономия каждый день Самый недооценённый режим — переводчик между человеческим и табличным. «Сумма оплат по клиенту за квартал, но только со статусом „закрыто" и без возвратов» — машина отдаёт формулу под ваш Excel или Google Sheets и объясняет её по частям. Обратное тоже работает: доставшаяся от уволившегося сотрудника формула на четыре строки вложенных условий расшифровывается в понятный текст за минуту. Мелочь на фоне контуров — но именно эти мелочи возвращают по 10–20 минут несколько раз в неделю, не требуют вообще никакой настройки и, что важно для команды, не пугают: с формул удобно начинать приучение сотрудников к машине — цена ошибки видна сразу, а польза очевидна с первого дня. Про то, как вводить инструменты без сопротивления команды, у нас есть отдельный опыт в разборе внедрения контроля звонков . Где анализ данных компании машине лучше не отдавать Для равновесия — три класса задач, где на сегодня я бы машине выгрузку не доверил или доверил с оговорками. Проверьте, нет ли вашей задачи в этом списке. Точная сверка до копейки. Бухгалтерская сверка, где важна каждая строка из десяти тысяч, — не задача для языковой модели: она может «устать» и обобщить. Для сверок — скрипты и формулы (которые машина, к слову, отлично напишет); ей самой — анализ расхождений, найденных скриптом. Прогнозы. «Спрогнозируй продажи на квартал» машина выполнит охотно и красиво — и это будет экстраполяция без понимания сезонности вашего рынка, запланированных акций и ушедшего ключевого клиента. Прогноз — работа человека с моделью в руках, не наоборот; про уверенные машинные прогнозы у нас есть отдельный скепсис в разборе про стратегию . Выводы о людях. Машина сравнит менеджеров по метрикам — но интерпретация «М8 ленится» против «М8 достаются худшие лиды» требует контекста, которого в выгрузке нет. Правило то же, что в примере 3: машине — проверку гипотез по данным, человеку — выводы о людях. Граница доверия: правила приёмки результата Теперь про то, где вас может подвести. Машина считает быстро и оформляет убедительно — это её сила и ваша опасность: неверный расчёт выглядит так же красиво, как верный. Наши правила приёмки аналитики от машины — те же, что для отчёта младшего аналитика: Логика — обязательная часть ответа. Какие строки вошли, какие исключены, по какой формуле счёт. Строка «покажи логику» стоит ноль, а превращает чёрный ящик в проверяемый расчёт. Контрольная сверка. Одну-две цифры из ответа сверьте с независимым источником — сводной таблицей, отчётом системы. Расхождение — почти всегда разница определений, и её полезно найти до совещания, а не на нём: про честный план-факт у нас есть отдельный разбор. Обезличивание перед загрузкой. В публичный чат данные идут без ФИО, телефонов и паспортов: имена — кодами («менеджер М3», «клиент К17»), анализу это не мешает. Полные данные — только в корпоративном контуре; правовая сторона разобрана в статье про персональные данные и нейросети . Где ломается Главный провал — не ошибка машины, а вопрос без определений. «Какая у нас конверсия?» — вопрос-ловушка: из лидов в сделки или из сделок в оплаты, за какой период, с дублями или без. Машина выберет трактовку сама, оформит красиво, и цифра уйдёт в решения. Лечится привычкой: каждый вопрос к данным начинается с определений — и это дисциплинирует не только машину, но и совещания, где годами спорили о «конверсии», считая её по-разному. Экономика вопроса Посчитаем на условной компании. Аналитика в штате нет; вопросы к данным возникают три-четыре раза в неделю, и раньше каждый решался одним из двух способов: полчаса-час ручной возни руководителя со сводными таблицами — или «спрошу потом», то есть никогда. С машиной цикл «выгрузка → постановка → проверка логики → контрольная сверка» занимает 10–20 минут на вопрос (оценка) — экономия порядка 5–8 часов управленческого времени в месяц только на срезах, не считая находок-аномалий, у которых цена штучная и непредсказуемая: одна пойманная ошибка ввода на крупной сделке окупает годовую подписку. Сравнение с альтернативами тоже честное. Джуниор-аналитик стоит от сотни тысяч рублей в месяц и решает эти же задачи медленнее, зато растёт и берёт на себя постановку вопросов. BI-система даёт красивые дашборды по заранее придуманным вопросам, но молчит на вопросы новые. Машина закрывает ровно зазор между ними: быстрые ответы на новые вопросы без найма — при обязательной вашей приёмке. Это не «или-или»: у зрелой компании со временем есть и BI для регулярного, и машина для нового, и человек для главного. Регулярная аналитика: следующая ступень Всё выше — ручной режим: выгрузил, спросил, проверил. Когда вопросы становятся регулярными — еженедельная воронка, ежемесячный срез по клиентам — подноску данных пора убирать: через MCP-подключения машина читает таблицы и CRM сама, а агент по расписанию приносит готовую сводку с пометками отклонений: сбор отчётности перестаёт быть отдельной ручной работой. Ручной режим при этом не умирает — он остаётся местом, где вы задаёте новые вопросы, прежде чем сделать их регулярными. С чего начать: упражнение на один вечер Ритм, который у нас прижился: раз в неделю — 20 минут «вопросов к данным» по свежей выгрузке, с сохранением удачных постановок в библиотеку. Через месяц-полтора у постановок появляется характер вашей компании — свои определения, свои известные ловушки в данных, свои контрольные цифры, — и это уже половина регламента для будущего агента-аналитика. И назову вещь своим именем. Умение задать вопрос собственным данным и принять на него ответ — это новый управленческий навык, такой же базовый, как чтение отчёта о прибылях. Я считаю его сегодня обязательным: руководитель, который умеет спросить выгрузку и проверить логику ответа, стоит дороже руководителя, который ждёт, пока отчёт принесут. Навык осваивается не курсом, а повторением — примерно за месяц регулярных попыток. Не откладывайте до «когда будет время» — его не будет. Возьмите одну выгрузку, которая у вас и так есть: сделки за квартал, платежи за месяц. Обезличьте. Задайте машине три вопроса по нарастающей: срез («посчитай по месяцам…» — с правилами счёта), аномалии («проверь дубли и пустые суммы»), объяснение («что в этих данных выглядит странно для компании нашего профиля — только наблюдения, без советов»). Час вечера почти гарантированно даст вам две вещи: пару настоящих находок в собственных данных (дубли и пустые суммы есть у всех, кто не искал их специально) — и личное ощущение границы, где машине можно верить, а где нужна сверка. Это ощущение дороже любого чужого чек-листа, включая мой. И маленькое замечание напоследок. Компании, где вопросы к данным задают регулярно, отличаются от остальных не технологиями. Они отличаются тем, что там спор мнений на совещании заканчивается словами «давайте спросим выгрузку» — а не тем, кто громче. Разница в качестве решений накапливается месяцами и становится видна в цифрах через год. Начать этот отсчёт можно сегодня вечером. Если хочется не наощупь, а по шагам — у меня есть бесплатный курс для руководителей : работа с данными там отдельным блоком, с практикой на ваших выгрузках.

## Model Context Protocol: как ИИ подключается к CRM, таблицам и диску компании
URL: https://davidgerstein.pro/blog/mcp-podklyuchenie-ii-k-sistemam/
Дата: 2026-08-29
Направление: Операционное управление
Цифры: 3 слоя архитектуры · права по принципу нового сотрудника · чтение раньше записи
Коротко: Model Context Protocol (MCP, открыт в конце 2024 года) — протокол, через который ИИ-ассистент сам читает данные из систем компании: таблиц, CRM, диска, календаря — вместо ручного «выгрузил-вставил». Архитектура из трёх слоёв: хост (где живёт машина), коннектор (переводчик к конкретной системе), права (что именно разрешено). Готовые коннекторы есть для большинства массовых систем; к самописной системе коннектор пишется за 2–5 дней работы одного разработчика (оценка); настройка готового — от часа. Главное правило внедрения — относиться к подключению как к найму: права по минимуму, чтение раньше записи, боевые системы в последнюю очередь. В компании на 40 человек машина читает данные из систем, но не пишет в них без человека — это решение, а не техническое ограничение.

Примеры пересчитаны на условную компанию — механика и выводы из живой практики. Спросите себя: сколько раз за последний месяц вы или ваши люди делали выгрузку из CRM, чтобы что-то посчитать? А теперь умножьте на год. Вот это и есть цена того, что машина у вас не подключена к системам, — и платите её вы не деньгами, а вечерами. В гайде по Claude подключения занимают одну секцию. Здесь — по-настоящему: как устроено, что настраивается за час, а что за неделю, где вас ждёт дыра в безопасности и почему главное решение тут принимает не программист, а вы. Что такое Model Context Protocol простыми словами Model Context Protocol (MCP) — открытый стандарт, по которому ИИ-ассистент подключается к системам компании: облачным таблицам, диску, календарю, CRM — и читает оттуда данные сам, вместо ручной выгрузки. Подключение собирается из трёх слоёв: хост (где работает машина), коннектор (переводчик к конкретной системе) и права (что именно разрешено). Готовый коннектор к массовой системе настраивается за час-день, к самописной — пишется за 2–5 дней работы одного разработчика (оценка). Управленческая часть тут одна: решить, что открыть и в каком режиме. Какую проблему решает Model Context Protocol Смотрите, в чём тупик. Без подключений любой разговор с машиной о ваших данных начинается с ручного труда: выгрузить, почистить, вставить, объяснить, что в какой колонке. Для разовой задачи терпимо. Для регулярной — смертельно: «сводка по зависшим сделкам каждый понедельник» на практике означает, что кто-то каждый понедельник делает выгрузку. И этот кто-то — обычно самый занятой человек в компании. Автоматизация ломается не об ум машины. Она ломается об подноску данных. MCP — Model Context Protocol — решает ровно эту проблему. Это открытый протокол, опубликованный Anthropic в конце 2024 года и с тех пор поддержанный остальной индустрией: стандартный способ дать машине доступ к внешней системе. Аналогия, которая нам кажется точной: USB для ИИ. До стандарта каждое устройство требовало свой шнур; после — один разъём подходит ко всему. До MCP каждая связка «модель × система» программировалась отдельно; теперь коннектор пишется один раз — и работает с любым ИИ-хостом, который понимает протокол. Как это устроено: три слоя Слой Что это Решение на этом слое Хост Где живёт машина: приложение Claude, серверный агент, среда разработчика Кто и в каком режиме пользуется подключением Коннектор (MCP-сервер) Переводчик между протоколом и конкретной системой: таблицами, CRM, диском Какие операции вообще возможны Права Учётка и область доступа, под которыми работает коннектор Что из возможного разрешено именно этой машине Вот деталь, которую упускают в восторженных обзорах, а она стоит денег: коннектор определяет возможное , права — разрешённое , и это разные слои. Коннектор к CRM может уметь и читать, и создавать, и удалять сделки — но учётка, под которой он работает у вас, может иметь право только на чтение двух воронок. Правильная настройка живёт на слое прав, и это управленческое решение, а не техническое. Что это даёт руководителю: три сценария Вопросы к живым данным. «Какие сделки висят без движения дольше двух недель и у кого их больше всего?» — машина отвечает по текущему состоянию CRM, а не по позавчерашней выгрузке. Класс задач, где раньше стоял аналитик с выгрузкой, сжимается до вопроса, заданного по-русски. Что важно: вопросы не нужно программировать заранее — в этом отличие от классических интеграций с жёстким сценарием. Документы из папки. Машина читает договор прямо с корпоративного диска: «разбери риски в последней версии договора с клиентом К., сравни с нашей типовой формой». Двух шагов — найти файл и вспомнить, где лежит типовая форма, — больше нет. Регулярные сводки без подноски. Связка с агентом (подробно — в разборе про ИИ-агентов ): по расписанию машина сама собирает данные из подключённых систем и готовит отчёт. Именно на этой связке — подключения плюс агент — построены наши контуры: оценка звонков читает записи и пишет в свою таблицу, разбор документов берёт файлы из потока и возвращает извлечённые поля. Цена ручной подноски данных Чтобы решение о подключениях принималось не на ощущениях, посчитайте свою «подноску». В нашей условной компании еженедельная сводка по воронке до подключения выглядела так: выгрузка из CRM, чистка колонок, загрузка в чат, объяснение контекста — порядка 40 минут работы, 52 раза в год. После подключения тот же вопрос задаётся одной постановкой — около 5 минут на прочитать результат и уточнить (оценка). Выгрузил — почистил — вставил ~40 мин Через подключение ~5 мин посчитайте на своих цифрах регулярных задач с выгрузками в неделю минут на одну подноску данных ручная подноска ≈ {X} часов в год формула: задачи в неделю × минуты × 52 недели ÷ 60 Три задачи по 40 минут в неделю — это больше сотни часов в год, съеденных не анализом, а транспортировкой данных. Против этой цифры и взвешивается неделя на настройку подключений. Как это настраивается: реалистичный план Разберём три типовых случая по нарастанию сложности — с честными сроками из практики. Прикиньте, к какому случаю относится ваша ситуация. Случай 1: массовая система, готовый коннектор — час-день. Облачные таблицы, диск, календарь, популярные таск-трекеры: коннектор ставится из каталога, настройка сводится к авторизации и выбору области доступа. Единственная содержательная работа — решить, что именно открывать: не «весь диск», а папку; не «все таблицы», а нужные. Случай 2: массовая CRM — день-неделя. Коннекторы к популярным CRM — Битрикс24, amoCRM и другим — существуют, но здесь добавляется работа с правами внутри самой CRM: отдельная учётка для машины с ролью «только чтение нужных воронок». Неделю занимает не техника, а согласование: кто отвечает за эту учётку, кто видит журнал её действий, как её отзывают. Случай 3: самописная система — дни разработки. Коннектор — это небольшая программа, которая переводит запросы протокола в запросы к вашей системе. По нашей практике, для системы с готовым внутренним API это дни работы одного разработчика; сложность растёт не от MCP, а от состояния вашего API. Хорошая новость: писать коннектор нужно один раз — дальше он работает с любым хостом. Постановка для машины при работе через подключение выглядит буднично — и в этом суть: данные перестают быть событием: Обратите внимание на строку «ничего не меняй»: она дублирует ограничение прав. Это осознанная избыточность — граница, прописанная и в правах, и в постановке, переживает ошибку в любом одном из двух мест. Что внутри коннектора: для порядка величин Вам не нужно писать коннекторы. Но понимать масштаб полезно — иначе вы не сможете оценить ни срок, ни смету подрядчика. Коннектор — это небольшая программа, которая объявляет машине список своих «умений» (например: «найти сделки по фильтру», «прочитать карточку клиента», «список файлов в папке») и переводит каждое умение в запрос к вашей системе. Умение описывается названием, параметрами и текстом-подсказкой, по которой машина понимает, когда его применять. На этом устройство протокола, по сути, исчерпывается — остальное детали реализации. Отсюда, если вы заказываете коннектор снаружи или ставите задачу своему разработчику, два практических вывода. Первый: смета «коннектор к вашей CRM — три месяца работы команды» должна вызывать вопросы — либо в CRM нет вменяемого API и три месяца уйдут на него, либо вам продают лишнее. Второй: качество коннектора — это качество подсказок к умениям; если машина «не видит» данные или дёргает не тот инструмент, чинится обычно текст описаний, а не код — работа на часы. Безопасность: относитесь к подключению как к найму Теперь то, из-за чего я бы не спал, если бы делал это неаккуратно. Каждый коннектор — это доступ, выданный исполнителю, пусть и нечеловеческому. И решать, какой именно доступ выдать, придётся вам: раздача прав машине — базовый навык руководителя в компании, где работает автоматизация, тот же самый, которым вы решаете, кому из людей открыть договоры, а кому — только их реестр. Мои правила, выработанные там, где машина третий месяц читает рабочие данные: Права по минимуму. Не «доступ к CRM», а «чтение двух воронок под отдельной учёткой». Соблазн выдать пошире «чтобы два раза не ходить» — тот же, что при найме, и лечится так же: расширить доступ на порядок проще, чем разгребать последствия лишнего. Чтение раньше записи. Первые месяцы машина только читает. Право записи выдаётся по одной операции за раз — и в наши боевые системы машина не пишет до сих пор: таблица-черновик, которую человек может выбросить целиком, есть у каждого контура. Это решение, а не ограничение технологии. Учёт подключений. Список «какая машина куда подключена под какой учёткой» — такой же обязательный документ, как реестр доступов сотрудников : без него первый же аудит превращается в археологию. И персональные данные: если система содержит ФИО и контакты клиентов, подключение к ней — это обработка персональных данных со всеми выводами, разобранными в статье про нейросети и персданные . Где ломается Самый опасный сценарий — не взлом, а услужливость: машина с правом записи, получив двусмысленную задачу, «наводит порядок» в живых данных — переименовывает, дозаполняет, архивирует. Каждое действие по отдельности выглядит разумным, объём делает это катастрофой. Потому боевые системы и закрыты на запись: цена двусмысленной формулировки при чтении — плохой отчёт, при записи — восстановление базы из бэкапа. Типовые ошибки внедрения — по горячим следам Эти четыре ошибки я видел столько раз, что рискну предсказать: минимум одну вы совершите. Лучше заранее знать какую. Подключить всё сразу. Ваш энтузиаст за вечер цепляет к машине диск, почту, CRM и календарь. Через неделю никто не помнит, что открыто, через месяц это выясняет проверка. Правильный темп — одно подключение, одна регулярная задача на нём, и только потом следующее: подключение без задачи — это открытая дверь без причины. Одна учётка на всех. Машину подключают под личной учёткой владельца «потому что у него есть все права». Теперь машина видит всё, что видит владелец, включая то, что ей не нужно, а в журналах системы её действия неотличимы от действий человека. Отдельная учётка с именем вроде «ai-reader» решает обе проблемы и стоит десять минут. Доверить машине помнить контекст безопасности. «Мы же ей сказали не трогать боевые данные» — сказали в одном чате, а работает она в десяти. Ограничения живут в правах учётки, а не в памяти разговора; постановка их только дублирует. Любое правило, существующее лишь в виде просьбы к машине, следует считать несуществующим. Забыть про офбординг. Реестр подключений нужен не только для аудита: когда меняется система, увольняется ответственный или отзывается ключ, кто-то должен знать, что перевыпустить и где отключить. У доступа, как у сотрудника, есть не только первый день, но и последний. Когда Model Context Protocol не нужен И для честности — три случая, когда я бы вам это пока отсоветовал. Если регулярных задач с данными ещё нет — сначала месяц поработайте с выгрузками в чате: станет ясно, какие подключения реально нужны, обычно их две-три, а не десять. Если в компании не назначен ответственный за доступы — сначала наведите порядок с человеческими учётками, машинная станет ещё одной строкой в том же реестре, а не первой записью в пустом. И если единственная цель — «чтобы было как в демо у вендора»: интеграция без регулярной задачи под ней — это работающий, но бесполезный кран. Model Context Protocol и агенты: где сила связки По отдельности каждая технология — половина решения. Подключение без агента экономит подноску данных, но вопросы по-прежнему задаёте вы. Агент без подключений умеет действовать, но слеп — работает только с тем, что принесли. Настоящая автоматизация начинается в точке пересечения: агент, который через подключения сам берёт данные, сам выполняет регламент и приносит человеку готовый результат на приёмку. Практическое следствие для очерёдности внедрения: сначала подключения (они полезны сразу и без агентов), затем регламент на ручных прогонах, и только потом агент поверх. Обратный порядок — сначала «купить агента», потом думать, откуда он возьмёт данные, — регулярно встречается в коммерческих предложениях и стабильно заканчивается пилотом, который «почти работает». Подробно про очерёдность и жизненный цикл — в разборе про агентов . С чего начать И последний совет из опыта: заведите привычку раз в квартал перечитывать реестр подключений с одним вопросом — «пользуемся ли мы этим?». Подключения имеют свойство переживать задачи, под которые создавались; неиспользуемый доступ — чистый риск без пользы, и отключается он одной строкой. Порядок, которым шли сами и который советую вам. Первое подключение — к таблицам или диску: безобидно и полезно с первого дня. На нём — одна регулярная задача уровня еженедельной сводки. Месяц спустя — CRM в режиме чтения. Агенты поверх подключений — когда появится задача с потоком, см. разбор про агентов . И держите экономику на виду с первого дня — как мы считаем расходы , чтобы удобство не стало неучтённой статьёй бюджета. Что сделать на этой неделе: возьмите одну задачу, ради которой регулярно делается выгрузка, и посчитайте её по калькулятору выше. Дальше решение примете сами — цифра обычно убеждает лучше любой статьи. А если хочется пройти путь по шагам, с практикой на своих системах, — у меня есть бесплатный курс для руководителей , подключения там разобраны отдельным блоком. И имейте в виду одну вещь. Через год подключённая к системам машина будет такой же обыденностью, как сегодня телефон с почтой. Разница между компаниями будет не в том, у кого она есть, а в том, кто научился ею управлять раньше — и успел за это время перестроить работу.

## Автоматизация отчётности: во что выливаются полчаса ручного отчёта в день
URL: https://davidgerstein.pro/blog/zametka-otchet-rukami/
Дата: 2026-08-23
Направление: Операционное управление
Цифры: 30 мин/день · ~11 000 ₽/мес (оценка) · 22 рабочих дня
Коротко: Ежедневный получасовой ручной отчёт из CRM обходится примерно в 11 000 ₽ в месяц (оценка) — и ещё дороже стоит потерянная концентрация аналитика. Автоматизация такого отчёта — не проект, а выгрузка показателей из CRM без участия человека.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас кто-то каждое утро руками собирает отчёт из CRM — вы уже платите за это шестьдесят часов в год. Полторы рабочие недели человека уходят на копирование цифр из одного окна в другое. Строки «перенос данных вручную» в бюджете нет, поэтому вы этих денег и не видите. Планёрка, вторник, утро. Лена спрашивает аналитика: «Слушай, а почему у тебя отчёт по отделу продаж каждый день в 10:40 приходит, а не в 9:00, как договорились?» Аналитик пожимает плечами: «Я его руками собираю. Захожу в CRM, смотрю сделки за вчера, считаю средний чек, конверсию, свожу в таблицу. Минут тридцать уходит, иногда больше — если что-то не сходится и надо перепроверять». Тридцать минут в день звучит несерьёзно. Настолько несерьёзно, что три квартала подряд никто не спросил, зачем это делает человек, а не система. Если вы сейчас мысленно перебираете свои регулярные отчёты — считайте, что диагноз уже поставлен. Ручной отчёт из CRM: что показал разбор цифр Отдел, для которого она считает три показателя — выручку, средний чек, конверсию, — это 12 менеджеров с оборотом около 4 млн ₽ в месяц. Средний чек по опту — около 90 000 ₽. Все эти цифры уже лежат в CRM. Аналитик просто набирает их заново в таблицу — руками, каждый день, в одно и то же время. Я задал ей вопрос в лоб: «Ты сверяешь данные, когда переносишь, или просто копируешь?» Оказалось — второе. Проверка «сходится ли» происходит раз в неделю, по пятницам. То есть 30 минут в день — не аналитическая работа, а механический перенос цифр из одного окна в другое. При ставке аналитика около 1000 ₽/час (оценка) это 500 ₽ в день. При 22 рабочих днях — примерно 11 000 ₽ в месяц (оценка). За год — больше 130 тысяч ₽ (оценка). Деньги не космические, но это стоимость получаса, который никто специально не выделял: просто так сложилось. Настоящая цена не в деньгах. Вот что сказала сама аналитик, когда мы спросили, что мешает ей заниматься содержательной работой: «Я бы хотела погруженно работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать — это прям невероятная удача». Полчаса переноса цифр каждое утро — это ещё и разбитое начало дня: вы платите за час аналитики, а получаете полчаса. Что сделали: автоматизация отчётности вместо ручного переноса Лена задала свой любимый вопрос: «Кто владелец этого процесса — ты как аналитик или CRM как система?» Ответ очевиден: данные и так лежат в CRM, задача — не считать их руками, а вытащить. Вопрос про владельца здесь не риторический — с него начинается любой разбор процесса до узкого места и его хозяина . Настроили выгрузку трёх показателей напрямую из CRM в таблицу с автообновлением раз в час. Без нового софта и без разработки — штатный API системы, в которой уже ведутся сделки. Аналитик теперь ничего не переносит: цифры приходят сами, ей остаётся объяснять, почему конверсия просела в четверг. Скажу честно: автоматизировали три показателя, а не весь отчёт. Возвраты и региональная разбивка всё ещё требуют ручной сверки — источники в CRM и в бухгалтерии расходятся. Если у вас несколько версий одних и тех же цифр в разных выгрузках, это отдельная и более глубокая проблема, я разбирал её в статье про то, как поймал Битрикс24 на сдвиге дат . Здесь кейс проще: данные не врали, их просто перепечатывали. Вывод: чем обернулась история с отчётом Мы ещё не знаем, сколько времени в итоге освободится — через месяц смотрим, ушла ли аналитик от переноса цифр к объяснению, почему они такие. И следим, чтобы автоматизация не осталась без присмотра: по этой ловушке я отдельно разбирал кейс, где без ежедневного контроля процесс останавливался сам собой . Но первый эффект уже виден: отчёт приходит в 9:00, а не в 10:40, потому что его больше никто не собирает. Я и сам три квартала смотрел на этот отчёт и вопроса не задал — так что упрёк тут в первую очередь ко мне. Урок сформулировал так: если сотрудник каждый день в одно и то же время делает одно и то же механическое действие с данными, которые уже есть в системе, — это не про его дисциплину. Это про то, что никто не спросил, зачем здесь вообще человек. Спрашивать — отдельный навык руководителя, такой же рабочий, как умение читать бюджет: смотреть на регулярную работу и отделять перенос данных от выводов из них. Нужен ещё и контроль, который не зависит от памяти людей, — похожий принцип я разбирал на примере дебиторки . Что делаю теперь: раз в месяц прохожу по всем регулярным отчётам компании и по каждому решаю, где тратится время — на перенос данных или на выводы. Если на перенос — ищу, откуда вытащить цифры напрямую, вместо того чтобы поручать это человеку ещё раз, но быстрее. Ваш шаг на этой неделе: возьмите один регулярный отчёт, посчитайте его цену за год и покажите эту цифру тому, кто собирает его руками. Обычно после такого разговора автоматизация перестаёт быть «когда-нибудь» и становится задачей на неделю. Таких отчётов у вас почти наверняка больше одного, и каждый исполнитель уверен, что его случай особенный. Если вам непонятно, с какого конца за это браться, — разбираем по шагам в бесплатном курсе . Как выстроить отчётность целиком, чтобы такие получасовые дыры не появлялись, — там, где договариваются об одном источнике правды на каждый показатель .