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

Направление: Операционное управление — процессы и регламенты · узкие места · рутина под нож
Хаб направления: https://davidgerstein.pro/operacii/
Материалов в файле: 7 из 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.txt

## Риски внедрения ИИ: почему проект умирает уже после запуска
URL: https://davidgerstein.pro/blog/pochemu-vnedrenie-ii-ne-rabotaet/
Дата: 2026-08-22
Направление: Операционное управление
Цифры: 5 ошибок · 1 отзыв на 7139 оценок · цель занижена в 3 раза
Коротко: Внедрение ИИ проваливается не в модели, а в четырёх управленческих местах: нет ритуала разбора результатов, автоматизация не умеет чинить себя сама, данные CRM врут, пилот выдан за продакшен. На своём примере: система оценки звонков сделала 7139 оценок, но получила только 1 разбор от руководителя — и 25 000 ₽/мес эксплуатации ушли впустую.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш пилот с ИИ заглох — вы в большинстве. Разбираю пять причин, по которым внедрения умирают, хотя технически всё работало. Четыре из пяти я прошёл лично. За последний год я поставил в операционку среднего бизнеса несколько ИИ-контуров: оценку качества звонков, распознавание документов, отчётность для руководителей. Часть из них работает и приносит измеримую пользу. Часть — работает технически и не приносит ничего. Эта статья про вторую категорию, потому что про неё не пишет никто: агентства продают кейсы успеха, а самое дорогое знание лежит в провалах. Все ошибки ниже — мои собственные. Каждая стоила недель работы, и каждую можно было предвидеть. Какие риски у внедрения ИИ в компании? Главный риск не технический: система работает, а отдел — нет. Контур оценки качества звонков в компании на 40 человек сделал 7139 оценок, порядка 177 в день, и получил за весь период ровно один разбор от руководителя. Оценки были, ритуала разбора не было — и 25 000 ₽/мес эксплуатации ушли впустую. Остальные четыре риска той же природы: процесс, который молча останавливается и ждёт человека; данные CRM, которым поверили без проверки (12,9% лидов с изменённой задним числом датой); пилот, выданный за продакшен; эффект, посчитанный в технологиях вместо денег. Все пять проверяются одним вопросом: кто и когда в следующий раз посмотрит на результат системы и что после этого изменится в работе отдела. Ошибка 1. Вы считаете это технической задачей Самая частая и самая дорогая: вы отдаёте проект в ИТ и ждёте результата, а результат зависит от того, изменят ли люди свою работу. Технический запуск и управленческое внедрение — разные задачи. Система может оценивать сотни разговоров в месяц безупречно и не изменить ни одной цифры в продажах, если результаты этой оценки никто не разбирает с сотрудником. Мой самый поучительный провал выглядит так. Система оценки качества звонков: слушает все разговоры менеджеров, оценивает по чек-листу, показывает провалы. Технически — образцовая: за период эксплуатации она оценила 7139 разговоров, порядка 177 в день, себестоимость эксплуатации — около 25 000 ₽ в месяц. Ни один отдел контроля качества не даст такой охват за такие деньги. А теперь цифра, которая важнее: за весь период руководители оставили на эти оценки один отзыв . Один. Калибровка критериев оборвалась через месяц после запуска. Система продолжала оценивать — результаты никто не разбирал. 7139 — оценок звонков сделано 1 — разобрано с руководителем Технология заработала. Управленческая петля — нет. Оценка звонка что-то меняет только тогда, когда руководитель садится с менеджером и разбирает разговор. Этот ритуал никто не спроектировал: считалось, что «система покажет — люди увидят». Не увидят. У людей есть текущая работа, и новый экран с оценками в неё не встроен. Правило Ритуал разбора результатов проектируется раньше, чем модель. Если в плане внедрения нет строки «кто, когда и что делает с выводами системы» — внедрения нет, есть эксперимент за деньги компании. Ошибка 2. Робот, за которым приходится следить Автоматизация, которая требует, чтобы за ней следили, — это не автоматизация. Это вторая работа: вы не убрали задачу, а добавили к ней слежку за роботом, который её выполняет. Почему так выходит и как из этого выбираться, я разбирал отдельно — в тексте про автоматизацию, которая требует надзора . Вторая история короче. Автоматический процесс публикации контента упёрся в ошибку и молча остановился. Утром я обнаружил, что ничего не вышло, запустил руками, разобрался. Через неделю — снова. Фраза, которую я тогда сказал своему же ИИ-ассистенту, стала для меня определением проблемы: «Если бы я не пошёл к тебе, ничего бы не произошло» . У каждого автоматического процесса должны быть три вещи, и они дороже самой автоматизации: перезапуск после сбоя без человека, громкое оповещение, когда перезапуск не помог, и ответ на вопрос «работаешь ли ты прямо сейчас», который можно получить за десять секунд. Пока этих трёх вещей нет — процесс нельзя считать внедрённым. После того как я добавил все три компонента, картина изменилась: за следующий месяц процесс падал дважды, но оба раза перезапустился сам, а я узнал об этом из уведомления, а не из отсутствия публикации утром. Разница не в том, что процесс перестал ломаться — он ломается так же. Разница в том, что я перестал быть частью его схемы восстановления. Ошибка 3. Доверие к данным, на которых всё стоит ИИ-отчётность строится на данных CRM — а данные врут. Не метафорически: в один из месяцев я обнаружил, что у 12,9% лидов дата создания изменилась задним числом . Сдвиги накапливались, две выгрузки за один и тот же период давали разные числа. Отчёты, построенные на этих данных, были красивыми, убедительными и неверными — подробно я разобрал это в статье про враньё данных в CRM . Отдельный случай той же болезни — модели, которые убеждают сильнее, чем заслуживают. Первая версия стратегической модели, которую я собирал для совета директоров, показала рост выручки на 9 млн ₽ в год против утверждённого плана в 27 млн ₽ — ровно втрое меньше. Поймали до показа — сверкой с утверждённым планом. Если бы не поймали, руководство приняло бы решения на основе цифры, которая выглядела идеально и была неверна. Правило Дашборд на недостоверных данных опаснее отсутствия дашборда: он придаёт уверенность. Аудит достоверности данных — обязательная часть любого проекта отчётности, и он всегда находит расхождения. Всегда. Ошибка 4. Ваш пилот так и остаётся пилотом Признак: у проекта нет даты, после которой старый способ работы отключается. Пока она не назначена, ваша команда будет держаться за привычное. Рынок устроен так, что подрядчику выгодно продать пилот: быстро, дёшево, красиво на демо. Пилот почти всегда «успешен» — и почти никогда не доживает до ежедневной работы, потому что между демо и продакшеном лежит всё самое дорогое: обработка граничных случаев, права доступа, поведение при сбоях, обучение людей, встраивание в существующий процесс. На распознавании документов я прошёл этот путь целиком. На демо всё распознаётся прекрасно. В реальном потоке: сканы вверх ногами, один документ в пяти файлах, рукописные вставки, типы документов, которых нет в библиотеке. Точность извлечения ключевых полей у нас выросла с 59% до 85% — но не сменой модели, а месяцами калибровки под каждый из 79 типов документов и, главное, честным разделением потока на режимы: что обрабатывается автоматически, что — автоматически с проверкой человеком, что — только руками. Без этого разделения первая же ошибка на важном документе убивает доверие ко всей системе. После разделения структура потока выглядела примерно так: около 70% документов проходят полностью автоматически, порядка 25% — автоматически, но с обязательной проверкой человека, и около 5% система сама отправляет в ручную обработку, не пытаясь угадать (оценка). Именно эти 5% и были демонстрационным провалом на этапе пилота — подрядчик показывал только первую категорию. Ошибка 5. Считать эффект в технологиях, а не в деньгах «Мы внедрили нейросеть» — не результат. Результат — это «комплект документов, который менеджер раскладывал полтора часа, теперь раскладывается за минуты, и менеджер за день обрабатывает втрое больше клиентов». Если эффект нельзя сформулировать в часах и деньгах — его, скорее всего, нет, и технология поставлена ради технологии. Сколько это стоит в живых деньгах, я разбирал отдельно, на своих счетах за использование моделей — см. статью про реальные расходы на ИИ . Как встроить ритуал без ручного контроля Ритуал разбора результатов автоматизируется тем же контуром, что и сама оценка: вебхук раз в неделю выгружает данные и формирует готовую повестку встречи — тогда он не зависит от того, вспомнит ли руководитель отдела продаж открыть отчёт сам. Ниже — рабочая связка для CRM на Bitrix24, где оценки звонков уже пишутся в поля сделки. Вебхук раз в неделю собирает JSON с оценками, модель отбирает проблемные звонки и формирует повестку. Это ровно та часть, которой не хватило в моём кейсе из ошибки №1. Пример ответа модели на приведённых данных: Такая связка не заменяет встречу руководителя с менеджером — она убирает единственный шаг, на котором мой ритуал развалился: «зайти и посмотреть отчёт». Повестка приходит готовой, встречу остаётся провести. Экономика: во что обошлась ошибка №1 Настройка системы оценки звонков заняла ~20 часов, эксплуатация — ~25 000 ₽/мес. Потенциальный эффект при работающем ритуале разбора — если он всего на 2 сделки из 50 в месяц меняет исход — ≈ 360 000 ₽/мес (оценка). Мы получили не эту цифру, а ноль: ритуал не заработал, и все 25 000 ₽/мес ушли в эксплуатацию системы, которую никто не использовал по назначению. Пример на цифрах отдела. Восемь менеджеров, оборот отдела ~9 млн ₽/мес, средний чек ~180 000 ₽ — это 50 сделок в месяц. Если оценка звонков стабильно выявляет и чинит один типовой сбой у одного менеджера — например, менеджер не проговаривает следующий шаг, и сделка «подвисает», — и это спасает 2 сделки в месяц, эффект составил бы 2 × 180 000 = 360 000 ₽/мес. Это оценка потенциала, а не измеренный факт: у нас ритуал так и не заработал, проверить цифру на практике не удалось. Что мы не считаем эффектом: сам факт наличия 7139 оценок в системе. Оценки — это запас информации, а не поток денег. Пока их никто не разбирает с менеджером, они не конвертируются ни в одну сделку. За два месяца эксплуатации без ритуала расходы составили 25 000 × 2 = 50 000 ₽ чистых потерь — система работала, отдел продаж не изменился. Атрибуция здесь простая, потому что инициатива в этот период была одна: весь эффект — и его отсутствие — на счету системы оценки звонков, без наложения других изменений в отделе. Сводка: где именно возникают риски внедрения ИИ Пять ошибок дают одну и ту же картину: технический результат почти всегда лучше управленческого. Ниже — сведённая таблица по каждому случаю из этой статьи. Ошибка Технический результат Управленческий результат Цена простоя Оценка звонков 7139 оценок, 177/день 1 отзыв руководителя за весь период 50 000 ₽ за 2 месяца без ритуала Автопубликация Работает без сбоев большую часть времени Останавливается молча, нужен человек для перезапуска ручной контроль каждую неделю CRM-отчётность Дашборд построен и выглядит убедительно 12,9% лидов с изменённой задним числом датой решения на основе неверных цифр Стратегическая модель Модель считает и визуализирует прогноз Занизила цель по выручке в 3 раза (9 млн ₽ вместо 27 млн ₽) риск утверждения неверного плана советом директоров Распознавание документов Точность выросла с 59% до 85% Итог дали месяцы калибровки, а не смена модели месяцы дополнительной настройки Общий знаменатель виден без комментариев: в каждой строке техническая часть выполнена, а управленческая — нет. Это не совпадение, это структура проблемы. Чек-лист на понедельник Пять проверок из этой статьи можно сделать за один рабочий день, не дожидаясь следующего провала. Проверить, кто и когда в последний раз разбирал результаты работающей ИИ-системы — если ответа нет, ритуал не работает. Найти в каждом автоматическом процессе точку молчаливого падения — и проверить, есть ли на неё оповещение. Сверить одну и ту же выгрузку из CRM дважды с интервалом в неделю — если числа разошлись, отчётности пока нет. Сравнить любую модель прогноза с утверждённым планом вручную, прежде чем показывать её руководству. Спросить у подрядчика, что происходит с кейсом, который не подходит под стандартный сценарий — ответ «такого не бывает» означает пилот, а не продакшен. Что из этого следует Внедрение ИИ проваливается не там, где ожидают. Не в модели — модели сейчас хороши. Оно проваливается в четырёх местах: в отсутствии управленческого ритуала вокруг системы, в автоматизации без самоконтроля, в данных, которым поверили без проверки, и в пилоте, который выдали за продакшен. И назову вслух то, что за этими пятью рисками стоит. Довести машину до эксплуатации — это отдельный управленческий навык, такой же осваиваемый, как бюджетирование или постановка задач. Он складывается из трёх умений: спроектировать ритуал разбора раньше, чем модель; потребовать у процесса самоконтроль вместо вашего внимания; проверить данные до того, как на них построен ваш отчёт. Руководитель, который этим владеет, стоит дороже руководителя, умеющего только раздавать задачи людям: первый масштабирует отдел через машину, второй — только через найм. Я этот навык осваивал задним числом, на своих же провалах, и это самый дорогой способ. Все четыре — управленческие задачи, а не технические. Поэтому и заниматься ими должен тот, кто отвечает за результат отдела, а не тот, кто сдаёт проект по акту. Как эти места проходят по календарю — маршрут на два-три месяца и три развилки, на которых всё ломается . Если вынести из этой статьи одно правило, пусть это будет такое: перед тем как подписывать акт о внедрении, спросите не «работает ли система технически», а «кто и когда в следующий раз посмотрит на её результат и что после этого изменится в работе отдела». Если ответа нет — акт подписывать рано, сколько бы разговоров система ни успела оценить. Проверьте свой проект по этим пяти пунктам прямо сейчас. Если найдёте хотя бы два — у вас есть недели две, чтобы что-то исправить, прежде чем команда окончательно потеряет к нему интерес. Как доводить до эксплуатации, а не до демо, — по шагам в бесплатном курсе для руководителей . И проверьте ваш проект на главный признак: назначена ли дата, когда старый способ работы отключается. Если нет — ваш пилот останется пилотом, каким бы хорошим он ни был.

## Контроль задач сотрудников: делегирование, которое не возвращает работу вам
URL: https://davidgerstein.pro/blog/delegirovanie-bez-poteri-kontrolya/
Дата: 2026-08-01
Направление: Операционное управление
Цифры: 11 000 ₽/мес возврата времени на отчёте · 9 000 ₽/мес переплата за 12 лишних каналов связи · 540 000 ₽/мес риск от зависших сделок (оценка)
Коротко: Контроль задач сотрудников работает не тогда, когда сотрудник согласился взять задачу, а когда есть три опоры контроля: структура дня, единый источник данных и инструкция, закреплённая после 3 итераций. Без этого делегирование превращается либо в перекладывание рук, либо в постоянные перебивания, которые возвращают задачу обратно на стол руководителя.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Вы делегируете, а потом всё равно проверяете каждый шаг? Значит, вы не делегировали — вы просто добавили себе ещё одну задачу: контроль. Проблема почти всегда в одном: задача передана, а критерий приёмки — нет. Человек не знает, каким должен быть результат, вы не знаете, когда можно отпустить, и оба страдают. Финансовый сотрудник жаловался, что коллеги дёргают его весь день с просьбами об оплатах. Основную работу не успевал, начал сомневаться в своей компетентности. Разбор показал: проблема не в человеке. В расписании не было слота под платежи. Как только появилось окно с 10 до 11 — именно на обработку операций, — перебивания не исчезли полностью, но перестали быть системой. Это и есть делегирование задач руководителем в чистом виде: не «возьми на себя», а «вот структура, в которой твоя ответственность работает». Большинство проблем с делегированием — это не проблема доверия. Это отсутствие структуры, в которую можно делегировать. Я сам года два считал, что дело в людях: не тянут, не хотят, надо искать других. Дело было в том, что я не давал им структуры, — и это моя недоработка, а не их. Ниже — с чем я сталкивался, сколько это стоило в деньгах и что чинил. Как контролировать задачи сотрудников без микроменеджмента Не проверять каждый шаг, а закрыть три опоры: фиксированный слот в расписании под конкретный тип задач, один источник данных вместо трёх разных выгрузок и инструкция, закреплённая после третьей итерации. Дальше руководитель смотрит не на задачи, а на отклонения — сводка приходит в 9:00 сама, без вопроса «как дела». Цена отсутствия такого контроля считается в деньгах: 11 часов в месяц (≈ 11 000 ₽) на ручной отчёт, ≈ 9 000 ₽/мес переплаты за 12 лишних каналов связи и до 540 000 ₽/мес риска по зависшим сделкам без владельца (оценки). Делегирование задач руководителем — это не «отдать руки», а построить систему Показательный разговор: менеджер ведёт три проекта, в каждом по пять треков. Просит помощника. Ему дают одного человека — «ещё одну пару рук». Не помогает. Потому что задача не в нехватке рук, а в отсутствии структуры распределения: нужны не руки, а три отдельных зоны ответственности, каждая со своим человеком и своими границами. Если этого нет — любой помощник превращается в ещё один канал, который надо контролировать вручную. Скажу прямо: собрать контроль задач сотрудников так, чтобы он держался без вас, — это отдельный управленческий навык, и осваивать его придётся так же, как когда-то осваивали бюджетирование. Руководитель, который умеет построить структуру, где работа идёт без его личного присутствия, стоит дороже руководителя, который умеет только раздавать поручения и потом их выбивать. Я этот навык добирал на ходу и с потерями. Корень проблемы обычно один: у руководителя нет навыка постановки задачи. Не в смысле «не может объяснить», а в смысле — не разбивает работу на единицы, которые можно передать целиком, с понятной границей и результатом. Пока задача не разбита, делегирование выглядит как «на, разберись», а это не делегирование, это перекладывание неопределённости. Контроль задач сотрудников: почему таблицы и память подводят Проверьте себя: сколько задач вы держите в голове прямо сейчас и сколько из них вы вспомните завтра без напоминания? Классический симптом — данные, которые врут в зависимости от того, кто и как их выгрузил. У нас была ситуация: список клиентов из воронки одного региона выгружали трижды, получили три разных числа. Это не ошибка одного сотрудника. Это децентрализованное хранение: у каждого свой фильтр, своя версия правды, и руководитель тратит время не на управление, а на поиск, какая цифра настоящая. Отдельно я разбирал похожий случай с датами, которые сдвигались в самом Битрикс24 — там источник ошибки был не в человеке, а в системе, но принцип диагностики тот же: сначала найти, где именно врёт цифра, потом чинить. Контроль исполнения задач нельзя строить на том, что кто-то посмотрит таблицу и скажет «всё ок». Мы заменили ручную проверку ботом: он ежедневно присылает, сколько звонков было вчера, сколько добавлено сегодня, на сколько отстают от плана. Менеджеры складывают записи в структурированную папку под своей учёткой, система агрегирует сама. Руководителю не нужно спрашивать «как дела» — у него есть цифра без интерпретаций. Отдельно — дашборд для руководителей подразделений: маркетинг, продажи, платёжный календарь, персональное обслуживание в одном месте вместо блуждания по CRM и таблицам. Добавили вкладку «ВИП-контроль» для клиентов с чеком, кратно превышающим средний по базе, — ежедневная проверка статусов с быстрым переходом в CRM, если нужно копнуть глубже. Смысл не в том, чтобы видеть всё. Смысл в том, чтобы видеть отклонение и разбираться только с ним. Дашборд руководителя подразделения 52 подключённых канала за месяц 78% план по звонкам, Смирнова А. Топ-15% порог для ВИП-контроля по чеку Раздел Статус Маркетинг норма Продажи внимание Платёжный календарь норма ВИП-контроль (чек в разы выше среднего) проверить Было Стало Руководитель спрашивает в чате «как продвигается» Бот присылает статус автоматически по расписанию Три разные выгрузки — три разных числа Один источник данных, агрегация по пользователю Отчёт готовится вручную перед планёркой Сводка собирается сама к началу дня Контроль = проверка вручную каждой задачи Контроль = реакция на отклонение от плана Похожая логика — в подходе к заполнению CRM менеджерами : пока внесение данных держится на памяти и добросовестности человека, оно будет проседать. Система должна делать это за него или ловить момент, когда он этого не сделал. ИИ-связка: как собрать сводку без ручного сведения Дашборды и боты выше — это уже готовые продукты. Но конвейер, который их кормит, можно собрать за один день на связке «Bitrix24-вебхук → таблица → модель → Telegram», без разработки с нуля. Вот как это выглядит по шагам: Bitrix24-вебхук раз в сутки, в 8:00, выгружает задачи и сделки, изменённые за последние 24 часа, плюс текст голосовых сообщений сотрудников (уже расшифрованный отдельным сервисом). Данные складываются в Google Sheets построчно — по одному сотруднику на строку, с полями: должность, план по звонкам, факт, просроченные задачи. Скрипт (Google Apps Script или сценарий в Make/n8n) собирает JSON по каждому сотруднику и отправляет его в языковую модель с промптом на структурирование и приоритизацию. Модель возвращает строгий JSON: приоритет, отклонение, ключевое событие дня. Telegram-бот в 9:00 публикует сводку руководителю и, при необходимости, самому сотруднику — до начала рабочего дня, а не по запросу. Модель на этом шаге — дешёвая, а не топовая. Мы уже проверяли на другой задаче: разработчик гонял промпт через дорогую модель (Opus), хотя более дешёвая версия (Sonnet) на том же входе давала идентичный результат. Здесь задача та же по природе — структурирование и классификация по понятным правилам, а не творческая генерация. Переплата за флагманскую модель тут не окупается ничем, кроме иллюзии надёжности. А где разница между дешёвой и дорогой моделью действительно видна — в разборе того, что машина вытягивает на текстах, документах и таблицах . Пример ответа модели на реальном по структуре входе: Что делать, если дешёвая модель на этой конкретной задаче начинает систематически путать приоритеты — например, ставит «норма» при явной просрочке в 3 дня. Опыт с Opus/Sonnet выше был про другую задачу, здесь порог принятия решения свой, и его надо проверять отдельно. Порядок действий такой: сначала ужесточить промпт числовыми порогами (это уже сделано выше — «> 2 дней», «70–90%»), затем добавить 3–5 few-shot примеров именно тех кейсов, где модель ошибалась, и только если после этого доля ошибок в приоритете выше приемлемой (условно — чаще одной ошибки на 20 сводок), переходить на модель среднего уровня. Смена модели — последний шаг в этой цепочке, не первый; в девяти случаях из десяти проблема лечится промптом, а не ценой токена. Инженерная обвязка простая и без иллюзий: сценарий крутится в Make (или n8n на своём сервере), лог всех входов и ответов пишется в отдельный лист Google Sheets — это и есть журнал для разбора, если что-то пошло не так. Если API модели вернул ошибку или таймаут — три автоматических повтора с интервалом 5 минут, при третьей неудаче алерт уходит в отдельный технический чат «бот молчит», а не теряется молча. Если ответ модели не парсится как валидный JSON — строка помечается флагом и уходит человеку на ручную проверку вместо того, чтобы тихо выпасть из сводки. Прозрачность без ежедневных пересказов Ваша цель — видеть статус, не спрашивая. Если для понимания картины нужна планёрка, вы платите за неё временем всей команды. У руководителя, который держит в голове десятки процессов, обычно нет времени вникать в каждую задачу отдельно. Решение, которое сработало у нас: все встречи, записи и задачи агрегируются в одну сводку, которая приходит утром с приоритизацией по должностям и автоматическим распределением новых задач. Это не отчёт для галочки — это способ не упустить важное, не читая десять источников. То же с постингом в соцсети: менеджеры записывают голосовое сообщение по итогам дня, оно попадает в единый агрегат, транскрибируется и упаковывается в контент. Единственная сложность — заставить людей делать эту рефлексию ежедневно, потому что живой контент требует живого источника. Автоматизация решает упаковку, но не решает дисциплину на входе. Это ограничение я обхожу молча реже, чем стоило бы. В статье о планёрках, которые документируют себя сами , — тот же принцип: прозрачность задач сотрудников держится не на том, что все стали ответственнее, а на том, что фиксация перестала зависеть от человека, который вечно спешит. Где ломается Делегирование без структуры превращается в перебивания и хаос — сотрудник получает задачу, но не получает границ, времени и точки, куда обращаться с вопросами. Результат: он либо тонет, либо возвращает задачу руководителю в виде постоянных уточнений. То же с автоматической сводкой: если голосовые сообщения или данные из CRM перестают приходить регулярно (человек забыл, канал отвалился), сводка молчит или показывает пустые поля — и это выглядит как «всё в порядке», хотя на деле источник просто не сработал. Прежде чем делегировать или автоматизировать контроль, нужно ответить на вопрос: в какое время, в каком канале и с каким результатом это должно происходить. Если ответа нет — делегировать пока нечего. Инструкция вместо повторного объяснения Работающая практика: каждое новое действие сотрудника либо документируется в виде инструкции, либо записывается на диктофон для расшифровки. Логика простая — три итерации: неправильно, неправильно, правильно. После третьей, рабочей версии действие закрепляется инструкцией, и к вопросу больше не возвращаются. Это медленнее в моменте и быстрее на дистанции: рутина превращается в процесс, который можно передать новому человеку без повторного объяснения с нуля. Без этого шага делегирование упирается в стену: каждый новый сотрудник задаёт те же вопросы, что и предыдущий, а руководитель отвечает на них лично — то есть фактически не делегировал, а нанял себе ещё одного человека, требующего внимания. Разделение ролей — тоже форма делегирования Не всегда проблема в задачах. Иногда — в том, что одна роль требует двух разных типов внимания одновременно. У нас менеджер не мог одновременно обучать новичков и вести опытных продавцов — это разные режимы работы, и попытка совмещать их в одном человеке приводила к тому, что страдали обе группы. Решение — разделить: один занимается только стажёрами, другой — действующими менеджерами. Ещё пример: сильный сотрудник без свободного времени в дне, с карьерными амбициями, упёрся в потолок. Вместо увольнения или игнорирования ей предложили возглавить проект автоматизации — это одновременно решило её потолок и операционную проблему компании. Делегирование здесь шире, чем «дать задачу»: это распределение ответственности так, чтобы она соответствовала возможностям и мотивации человека, а не только штатному расписанию. Обратный пример упущения — руководитель отдела разработки долго не был подключён к планёркам по автоматизации, хотя все обсуждаемые задачи были техническими и касались его напрямую. Это не делегирование, это исключение из контура человека, который должен был быть его частью с самого начала. Это моя ошибка: я не позвал его вовремя. Вскрылось не сразу — и стоило времени на пересборку процессов задним числом. Сколько стоит несистемное делегирование — и что даёт система Три расчёта ниже, каждый со своей ценой и эффектом: ручной отчёт — это 11 часов в месяц (≈ 11 000 ₽, оценка по ставке); лишние каналы связи — 12 линий и ≈ 9 000 ₽/мес переплаты (оценка); зависшие сделки без владельца — риск ≈ 540 000 ₽/мес (оценка). Это три разные задачи с разными исправлениями, не одна и та же экономия, посчитанная трижды. Ручной отчёт. Формула: (минуты в день ÷ 60) × рабочие дни в месяце × ставка сотрудника в час = потери времени в деньгах. Аналитик тратил около 30 минут в день на ручное заполнение ежедневного отчёта (показатель, средний чек, конверсия) — это факт, не оценка. Подставляем: 0,5 часа × 22 рабочих дня = 11 часов в месяц. По ставке около 1 000 ₽/час (оценка, ориентир для сотрудника аналитического уровня) это 11 часов × 1 000 ₽ ≈ 11 000 ₽/мес чистого времени, которое можно вернуть аналитику на аналитику, а не на копирование цифр. Возьмите свои минуты и свою ставку — формула та же. Разрастание каналов связи без контроля. Формула: количество лишних подключённых линий × стоимость одной линии в месяц = переплата. В компании ~40 человек за несколько месяцев число оплаченных коммуникационных линий выросло до 27, хотя реально с внешними клиентами работают около 15 человек (8 менеджеров продаж и часть поддержки). Разница — 12 лишних линий: WhatsApp и Telegram подключены по отдельности почти у каждого, хотя нужен один канал. Одна линия стоит ~750 ₽/мес. 12 × 750 ₽ ≈ 9 000 ₽/мес переплаты (оценка) — деньги, которые уходили не за связь с клиентами, а за то, что право подключать канал делегировали, а точку контроля над этим правом — нет. Аудит и отключение дублей — это не разработка, это полчаса работы с биллингом провайдера, но без выделенной ответственности за него никто не потратил эти полчаса три месяца подряд. Зависшие сделки без владельца. Формула: поток сделок в месяц × доля зависших без контроля × доля тех, что в итоге срываются × средний чек = риск в деньгах. При обороте отдела продаж ~9 млн ₽/мес и среднем чеке ~180 тыс. ₽ поток — около 50 сделок в месяц. Если из-за отсутствия контроля исполнения около 10% сделок зависают без явного владельца (никто не назначен ответственным за следующий шаг) — это 5 сделок в месяц. Из них 2 всё же закрываются, просто позже, а 3 — по консервативной оценке — срываются: клиент не получил ответа вовремя и ушёл к конкуренту или остыл. Риск: 3 сделки × 180 000 ₽ ≈ 540 000 ₽/мес (оценка). Это не фактическая потеря, а верхняя граница риска при текущей доле зависания — но именно она обосновывает, почему владелец у каждой сделки должен быть назначен явно, а не подразумеваться. Идут по плану — 45 сделок (90%) Зависли, но закрылись — 2 сделки (4%) Зависли и сорвались — 3 сделки (6%) Важная оговорка по всем трём цифрам: они не складываются в единый эффект одного и того же внедрения. Ручной отчёт чинится интеграцией CRM с таблицей — это отдельная задача. Каналы связи чинятся аудитом биллинга — вторая задача. Зависшие сделки чинятся точкой контроля (бот, дашборд, явный владелец на каждом этапе) — третья. Если вы одновременно наводите порядок во всех трёх, экономия суммируется; но приписывать все три результата, скажем, одному только Telegram-боту со сводкой — было бы натяжкой: сдвиг дают разные меры, вклад каждой по отдельности можно посчитать только там, где мы это явно сделали выше. Отдельно: что мы не считаем эффектом. 11 000 ₽/мес по отчёту — это высвобожденное время аналитика, а не сокращение фонда оплаты труда: человек остаётся в найме, время просто уходит на более сложную аналитику. Деньгами это становится только тогда, когда высвобожденные часы дают измеримый результат — больше отчётов без найма нового человека, меньше переработок. Пока это не так — это поток свободного времени, а не поток денег. Чек-лист на понедельник Выписать 3 задачи, которые вы делегировали за последний месяц, но которые всё равно возвращаются к вам вопросами. Для каждой — определить: не хватает границы, времени в расписании или инструкции. Проверить, есть ли у каждой сделки в работе явный владелец следующего шага. Если ответственность подразумевается, а не назначена — риск зависания есть уже сейчас. Сверить число подключённых коммуникационных каналов (WhatsApp, Telegram, другие линии) со списком сотрудников, которым они реально нужны. Разница — это переплата, которую можно отключить сегодня же. Для одного повторяющегося ручного отчёта посчитать: минуты в день × рабочие дни × ставка сотрудника. Если сумма заметна — это кандидат на автоматизацию через выгрузку из CRM, а не на «доделаем как-нибудь». Для одного нового действия, которое сотрудник выполняет впервые, — решить заранее: документируем сразу как инструкцию или записываем на диктофон для расшифровки после третьей итерации. Ни один из этих пунктов не требует бюджета на разработку. Все они требуют одного — назначить, кто и когда на это смотрит. Контроль задач сотрудников в итоге сводится именно к этому: не к тому, что вы отдали работу, а к тому, что вы построили структуру, в которой эта работа не возвращается к вам сама. Сделайте на этой неделе эксперимент: передавая следующую задачу, потратьте две минуты на формулировку «по какому признаку я приму результат». Не «сделай хорошо», а конкретно. Это единственное изменение, которое снимает половину вашего контроля. Я бы начал ровно с него — оно ничего не стоит и работает уже завтра. Как выстроить это системно — и почему то же правило работает с машинными исполнителями, — в бесплатном курсе . Контроль держится на цифрах, которым можно верить. Как их получить — там, где разбирается источник, хозяин и срок обновления каждой цифры .

## Протокол планёрки, который пишется сам
URL: https://davidgerstein.pro/blog/protokoly-planerok-avtomatom/
Дата: 2026-07-27
Направление: Операционное управление
Цифры: ~70 часов в месяц экономии для отдела из 15 менеджеров (оценка) · время на переспрашивание сокращается в разы с автопротоколом · окупаемость около 1–2 месяцев
Коротко: Автоматический протокол планёрки — это связка «запись → расшифровка → структурированные задачи», где человек не набирает текст руками. По грубой оценке, для отдела из 15 менеджеров это экономит около 70 часов в месяц (оценка), которые раньше уходили на переспрашивание задач. Работает только если задачи сразу попадают в CRM или таск-трекер со сроком и ответственным, а не остаются текстом в чате.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Половина решений с ваших планёрок теряется в течение недели. Не потому что люди безответственные — потому что никто их не записал, а память у всех своя. Если вы через три дня после планёрки переспрашиваете собственных сотрудников, о чём же вы там договорились, — у вас нет протокола. У вас есть коллективное воспоминание, и оно расходится с реальностью тем быстрее, чем больше людей сидело в переговорке. Плохо не то, что вы что-то забыли. Плохо, что вы не можете проверить, кто прав. У меня есть цитата от финансового сотрудника, которую я храню как напоминание себе: «Я бы хотел погруженно работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать без перерыва — это невероятная удача». Дело не в перегрузке. Дело в том, что человека дёргают вопросами, ответы на которые уже прозвучали на планёрке пять минут назад — просто их никто не записал. Автоматический протокол планёрки — не бюрократическая прихоть для галочки, а способ вернуть людям эти самые 15 минут концентрации. Обратный пример из той же компании: руководителя отдела разработки просто не звали на технические планёрки по внедрению ботов и автоматизации — хотя эти задачи напрямую касались его работы. Собственник узнал об этом случайно и назвал упущением. Причина проста: не было единого места, куда стекались бы решения со всех встреч. Кого не позвали — тот не в курсе, а переспрашивать неудобно. Протокол, который расходится сам, без участия человека на этапе набора текста, закрывает и эту проблему тоже — не только проблему забытых задач. Как автоматически составить протокол планёрки Протокол планёрки — рабочая запись встречи из трёх списков: решения, задачи с ответственным и сроком, вопросы без ответа. Собрать его автоматически можно так: запись встречи → расшифровка речи → постановка задачи машине «сделай протокол из этих трёх списков». Обязательная строка в постановке — «если срок или ответственный не назван, пометь и не придумывай». Экономия на отделе из 15 человек — порядка 70 часов в месяц (оценка), и не на письме протокола, а на том, что решения перестают переспрашивать заново. Зачем вам протокол планёрки Не для отчётности. Для того, чтобы через неделю вы могли проверить, сделал ли ваш человек то, о чём договорились, — не по памяти, а по записи. Без протокола планёрка живёт ровно до момента, пока участники не разошлись по делам. Дальше начинается пересказ по памяти, и каждый помнит немного своё. Я видел, к чему это приводит на уровне данных: при попытке выгрузить список клиентов одного региона из воронки CRM получили несколько разных чисел, заметно расходящихся между собой. Причина — децентрализованное хранение информации, никто не сверялся с единым источником. С задачами из планёрок работает тот же механизм: если протокол не зафиксирован автоматически сразу после встречи, каждый участник уносит свою версию договорённостей, и через неделю выяснить, кто прав, уже нельзя. Похожий конвейер в компании уже отработан для другой задачи — автопостинга в соцсеть. Менеджеры записывают голосовое сообщение по итогам дня, оно попадает на единый агрегат, транскрибируется, упаковывается в пост и публикуется без участия человека. Единственная сложность там — заставить людей ежедневно наговаривать рефлексию, техническая часть работает стабильно. Протокол планёрки строится по той же логике: запись → расшифровка → структура → распределение. Меняется только то, что упаковывается на выходе: не пост для соцсети, а список задач со сроками и ответственными. Шаблон протокола планёрки: что должно быть в каждом Протокол работает, если в нём всегда одни и те же поля — тогда его можно и собирать машиной, и читать по диагонали. Наш набор такой: Дата, участники, кто вёл — чтобы через месяц было понятно, с кого спрашивать. Повестка — пункты, которые собирались обсудить. Расхождение повестки и обсуждённого — сам по себе диагноз. Решения — что постановили, отдельно от обсуждения. Формулировка в прошедшем времени: «решили», а не «обсудили возможность». Задачи: что, кто, к какой дате — три поля обязательны. Задача без имени и даты через неделю не существует. Вопросы без решения — то, что не закрыли. Этот блок переносится в повестку следующей встречи автоматически. Машина собирает такой протокол из расшифровки за минуты. Но заполнить поле «кто и к какой дате» она может только тем, что прозвучало вслух: если на встрече не назвали имя и срок, в протоколе будет пусто — и это тоже полезный сигнал. Механика по шагам Соберёте за день. Вам понадобится запись встречи и одна постановка задачи для машины — ни того, ни другого покупать не нужно. Раскладываю конвейер на шаги, которые можно повторить на своей команде без отдельного штата разработчиков. Протокол — удачный первый кандидат: процесс частый, ошибка в нём стоит дёшево, а результат виден всему отделу, то есть ровно те признаки, по которым выбирают процесс и доводят его до эксплуатации . Запись. Планёрка идёт в Zoom, Google Meet или просто на диктофон в переговорке. Источник аудио не принципиален — важно, чтобы запись велась постоянно, а не «когда вспомнили». Расшифровка. Аудио уходит в сервис распознавания речи. Для старта не нужно ничего разрабатывать: Яндекс SpeechKit и Salute Speech от Sber дают разметку по спикерам из коробки через обычный API-запрос, платите за минуты записи — удобно, если планёрок немного. Если записей много и хочется считать не в минутах, а в разовой настройке, — Whisper (открытая модель, можно развернуть на своём сервере) обходится дешевле в пересчёте на час при большом потоке, но требует один раз настроить инфраструктуру. На выходе в любом случае — транскрипт с таймкодами и, желательно, разметкой по спикерам. Структурирование. Транскрипт подаётся в языковую модель с промптом, который вытаскивает поручения: что сделать, кто отвечает, к какому сроку, на какой минуте это прозвучало. Передача в систему. Результат — не текст в чате, а структурированные записи, которые скрипт кладёт в CRM или таск-трекер через вебхук: задача, ответственный, дедлайн, ссылка на исходный фрагмент записи. Просмотр человеком. Руководитель или проект-менеджер один раз в день получает сводку: что добавилось, что просрочено, что требует подтверждения — и подтверждает или правит вручную. Последний шаг — не формальность. Без него автоматизация превращается в чёрный ящик, который никто не контролирует — с похожими последствиями я уже сталкивался на другой автоматизации в этой же компании, речь о ней ниже, в разделе про надзор. ИИ-связка: промпт, модель, обвязка Возьмите эту постановку как основу и подставьте свои разделы протокола: у вас может быть другой набор, важен принцип. Расшифровка сама по себе — самая дешёвая часть цепочки, около 2 000 ₽ в месяц при ежедневной получасовой планёрке. Дороже интеграция: связать запись с CRM, таск-трекером, распределить задачи по людям. И вот здесь легко переплатить, даже не заметив этого. В одной команде разработчик гонял тяжёлую модель (Opus) на задачах, которые дешёвая версия (Sonnet) решала одинаково хорошо. Проверили на одном и том же промпте — результат оказался идентичным. Для выделения задач из транскрипта планёрки это прямое указание: не нужна самая дорогая модель, чтобы превратить текст в список поручений. Дорогая модель имеет смысл там, где есть более глубокая смысловая нагрузка — например, оценка качества переговоров с клиентом, а не структурирование внутренней планёрки. Вот рабочий промпт для этапа «выделение задач из транскрипта». На входе — транскрипт с таймкодами и именами спикеров, полученный от сервиса распознавания речи. Модель — Sonnet или её аналог: задача чисто структурная, переплачивать за более тяжёлую модель здесь бессмысленно. Пример ответа модели на реальный кусок транскрипта планёрки, где обсуждали расхождения в выгрузке клиентов по региону: Смотрите: по первой задаче модель честно написала «уточнить» вместо того, чтобы придумать ответственного, — имя на записи просто не прозвучало. Такое поведение нужно закладывать в промпт явно, иначе модель начнёт галлюцинировать исполнителей. Вот как эти две задачи выглядят уже после того, как скрипт разложил их по CRM — так руководитель видит их в системе, а не в чате: Задачи из планёрки · CRM 2 задачи из транскрипта 1 ответственный не назван 1 срок подтверждён Задача Ответственный Срок Статус Свести три выгрузки клиентов по региону в один отчёт уточнить не назван Проверить настройки фильтра воронки в CRM Ирина 2026-07-29 Формат вебхука и структура очереди — для тех, кто будет собирать это руками JSON от модели не летит в CRM напрямую — между ними должна быть буферная очередь, иначе одна кривая расшифровка положит задачи с ошибками без возможности откатить. Практическая схема, которую я видел рабочей: Скрипт получает JSON-массив от модели и построчно пишет его в промежуточную таблицу (можно на первое время в Google Sheets, дальше — в БД): столбцы id, task_text, owner_raw, deadline_raw, timecode, confidence, status . Статус по умолчанию — pending . Отдельный воркер раз в 5–10 минут разбирает записи со статусом pending . Если confidence = low или owner_raw = «уточнить» — запись уходит в manual_review , задача не создаётся автоматически, а в Telegram руководителю приходит карточка с кнопками «создать» / «отклонить». Если confidence = high и имя из owner_raw находится в справочнике сотрудников (простой маппинг «имя → ID ответственного в CRM»), воркер отправляет задачу через API и меняет статус на sent , сохраняя ID созданной задачи для сверки при аудите. Пример запроса на создание задачи через REST-вебхук Bitrix24 (метод tasks.task.add ) для второй строки из примера выше: Для amoCRM логика та же, меняется только эндпоинт и поля: задача создаётся через API amoCRM в сущность «задачи» с привязкой к сделке по ID, а не через отдельный сервис задач, как в Bitrix24. Выбор платформы не принципиален — принципиально то, что между JSON от модели и записью в системе стоит очередь с проверкой уверенности, а не прямой пайп «расшифровал → создал». Если JSON невалиден или больше половины пунктов получили confidence «low» — система не создаёт задачи молча, а шлёт алерт в Telegram ответственному за автоматизацию: транскрипт кривой, нужно посмотреть руками. Перезапуск — по той же записи повторным вызовом, без пересборки всей цепочки. Где ломается Модель на слух путает похожие фамилии и созвучные цифры — особенно если участники говорят одновременно или запись сделана через плохой микрофон. Это не баг конкретного промпта, а ограничение распознавания речи в принципе. Решение то же, что для любой автоматизации: выборочная проверка, а не слепое доверие результату. Как задачи из совещания перестают теряться Ваше правило: задача без имени и срока в протоколе помечается как непоставленная. Это дисциплинирует участников быстрее любых напоминаний. В одной компании я видел рабочую конструкцию для этого — ежедневную сводку. Все встречи, записи и задачи агрегируются в одно резюме, которое приходит в Telegram со scoring по должностям и автоматическим распределением новых задач. Руководитель не читает протокол планёрки целиком — он получает уже отфильтрованный список: что касается лично его, что нужно передать дальше, что закрыто. Отдельно там же работает принцип для рутинных действий: каждое выполняемое задание либо документируется в виде инструкции, либо записывается на диктофон для последующей расшифровки. После трёх итераций — неправильно, неправильно, правильно — действие закрепляется инструкцией, и к вопросу больше не возвращаются. Тот же принцип применим к планёркам: не полагаться на память человека, фиксировать один раз и переиспользовать. Что именно должно попадать в протокол Формулировка задачи — не «обсудили», а «сделать X»; Ответственный — конкретное имя, не отдел целиком; Срок — дата, а не «в ближайшее время»; Ссылка на источник — таймкод записи, чтобы можно было проверить контекст. Без последнего пункта протокол превращается в пересказ, который через неделю нельзя проверить — а это именно то, что происходило с несколькими разными выгрузками по одному и тому же региону: никто не мог сказать, какая цифра верна и откуда она взялась. Задача конвейера Что нужно Где обычно переплачивают Расшифровка голоса в текст Яндекс SpeechKit / Salute Speech / Whisper на своём сервере Тяжёлая модель без необходимости Выделение задач из текста Дешёвая языковая модель (Sonnet и аналоги) + чёткий промпт Ручной перебор текста человеком Распределение задач по людям Интеграция с Bitrix24 / amoCRM через вебхук Копирование вручную в разные чаты Контроль исполнения Точки контроля и чеклисты Повторные напоминания в личке Вот как обычно распределяются трудозатраты на внедрение такого конвейера с нуля — по опыту, не точные часы: Настройка расшифровки ~10% Промпт для выделения задач ~20% Интеграция с CRM/трекером ~50% Обучение команды пользоваться ~20% На диаграмме — доля трудозатрат по каждому этапу настройки конвейера: больше всего времени уходит не на расшифровку и не на промпт, а на интеграцию с CRM или таск-трекером. Больше про экономию на моделях и реальные счета за токены я разбирал в статье о реальных расходах на ИИ — там же пример, когда правильная настройка лимитов сэкономила около 50 000 ₽ за одну ночь просто на выборе модели. Экономика: что это стоит и что даёт Настройка конвейера «запись → расшифровка → задачи в CRM» — это около 40 часов интеграции при ставке подрядчика ~2 000 ₽/час (≈80 000 ₽ разово), эксплуатация — около 2 000 ₽/мес на транскрибацию, эффект — примерно 70 000 ₽/мес высвобожденного времени менеджеров (оценка). Формула для прикидки своего случая словами: (число участников планёрки) × (минуты, которые в среднем уходят у каждого на переспрашивание задач в день) × (рабочих дней в месяц) / 60 = часы потерь в месяц; умножьте результат на свою почасовую ставку — получите сумму, которую сейчас незаметно съедает отсутствие протокола. Возьмём условный отдел из 15 менеджеров сервисной компании с оборотом около 12 млн ₽/мес и ежедневной 30-минутной планёркой. Без протокола каждый в среднем тратит около 15 минут в день на то, чтобы переспросить у коллеги или руководителя, что именно решили и кто за что отвечает — это ровно та ситуация, которую описывал финансовый сотрудник в начале статьи. Подставляем в формулу: 15 менеджеров × 15 минут × 22 рабочих дня / 60 ≈ 82 часа в месяц, потерянных на одном отделе. При ставке рабочего часа ~1 000 ₽/час это около 82 000 ₽ в месяц — только на переспрашивание, без учёта цены забытых договорённостей, если из-за них зависла сделка или не выставлен вовремя счёт. ~15 мин/день без протокола ~2 мин/день с автопротоколом Прикидка по времени на уточнение задач после планёрки, не абсолютные внутренние данные компании. Похожий паттерн уже встречался в той же компании в другой роли: аналитик отдела тратила около 30 минут в день на ручное заполнение ежедневного отчёта — основной показатель, средний чек, конверсия, — пока не подключили автоматическую выгрузку этих цифр из CRM. Масштаб другой, и вклад этой отдельной меры в общий результат компании отдельно не выделялся — но механизм тот же: ручной перенос данных из одного места в другое крадёт время, которое конвейер с ИИ возвращает на содержательную работу — будь то анализ отчёта или содержание самой планёрки. Стоимость эксплуатации не в расшифровке — она обходится примерно в 2 000 ₽ в месяц при разумном выборе модели, о чём и говорит история с Opus и Sonnet, давшими идентичный результат на одном промпте. Основные деньги уходят один раз: на интеграцию с CRM или таск-трекером и на настройку промпта под структуру конкретных планёрок компании. Откуда берётся раскладка трудозатрат на весь конвейер — не с потолка, а прямая раскладка по этапам с диаграммы выше, для интеграции среднего уровня сложности (одна CRM, один таск-трекер, без кастомных полей и без переписывания структуры данных): настройка и тест расшифровки — меньшая часть общего объёма (10%), доводка промпта на 10–15 реальных записях планёрок — заметно больше (20%), интеграция с CRM через вебхук — аутентификация, маппинг сотрудников на ID ответственных, обработка ошибок, буферная очередь, тестирование на боевых данных — основная часть работы (50%), обучение команды пользоваться и первые недели поддержки — ещё одна пятая часть (20%). Если CRM кастомная, полей для задач нет вообще или нужна интеграция сразу с двумя системами — время на интеграцию вырастет в полтора-два раза, и окупаемость ниже сдвинется соответственно. Дальше это около 70 часов высвобожденного времени в месяц на отдел из 15 менеджеров (82 часа минус 11 часов, которые остаются на уточнение и после автопротокола), которые больше никому не нужно объяснять заново — задача уже лежит в системе со сроком и ответственным. Что не считаем эффектом: если высвобожденные часы менеджеров просто перераспределяются на другую работу без роста числа закрытых сделок — это не доход, а перераспределение времени. В деньги эффект превращается только там, где время реально высвобождается, а не тратится на замену той же самой работы. Окупаемость по грубой прикидке: при ставке подрядчика на интеграцию около 2 000 ₽/час и объёме работ порядка 40 часов разовые вложения в проект составляют около 80 000 ₽. Экономия по времени в пересчёте на стоимость рабочего часа — около 70 000 ₽/мес — отбивает эти вложения примерно за один-два месяца. Дальше это уже чистое высвобождение времени, а не разовая экономия. Показатель Без протокола С автопротоколом Время на уточнение задач, час/мес на отдел из 15 менеджеров ~82 часа ~11 часов Стоимость этого времени при ставке ~1 000 ₽/час ~82 000 ₽/мес ~11 000 ₽/мес Источник истины по договорённостям Память участников Транскрипт с таймкодом Цифры в таблице — грубая прикидка по формуле «часы × ставка», не факт из системы учёта. Надзор всё равно нужен Соблазн включить систему и забыть о ней — самый частый способ сломать автоматизацию протоколов; проверять выборочно нужно каждые две-три недели, а не полагаться на то, что скрипт работает вечно без присмотра. Я видел похожую историю с коммуникационными каналами в этой же компании: в одном месяце было оплачено на порядок меньше линий, чем в следующем, — переплата шла за WhatsApp и Telegram на сотрудников, которых физически не было в таком количестве. Никто не следил, что система разрастается сама. Признаю: следить там должен был я, и не следил — это моя недоработка, а не сбой системы. Включённая автоматизация выглядит работающей ровно до первой выборочной проверки, и здесь ошибаются все, я в том числе. Так что если вы сейчас подумали «ну я-то проверю» — я тоже так думал. С автопротоколами планёрок риск тот же: если не проверять выборочно, что задачи реально долетают до исполнителя и срок в CRM совпадает со сроком на записи, система тихо начнёт врать — так же, как врёт CRM при рассинхроне дат, о чём я писал в статье про сдвиг дат в Битрикс24 . Про то, что любая автоматизация без периодической проверки превращается во вторую работу, а не в экономию времени, я подробно писал в статье про надзор за автоматизацией . Протокол планёрки — не исключение: раз в две-три недели стоит выборочно сверить три-четыре записи с тем, что реально попало в задачи. Это 15-20 минут проверки против часов ручного набора текста, которые экономятся каждую неделю. Возвращаясь к финансовому сотруднику с его 15 минутами концентрации: его проблема решилась не автоматизацией, а структурой дня — конкретным часом на обработку платежей. Протокол планёрки решает соседнюю проблему: он убирает необходимость держать в голове десяток устных договорённостей и пересказывать их по три раза за день. Это не заменяет управленческое решение о структуре дня, но освобождает время, чтобы его вообще успеть принять. Чек-лист: с чего начать в понедельник Выберите одну регулярную планёрку — не самую важную, а самую частую — и начните записывать её постоянно, без исключений. Подключите сервис расшифровки речи с таймкодами и разметкой по спикерам: для старта проще всего облачный API (Яндекс SpeechKit или Salute Speech), при большом потоке записей выгоднее Whisper на своём сервере. Возьмите промпт из этой статьи, прогоните на одной реальной записи и сверьте результат вручную — сколько задач модель нашла верно, сколько пропустила, где ошиблась с ответственным. Настройте передачу результата в CRM или таск-трекер через вебхук с промежуточной очередью и статусами pending/manual_review/sent — не в чат, чат не считается системой хранения задач. Назначьте человека, который раз в две-три недели выборочно сверяет 3-4 протокола с записью — это тот самый надзор, без которого автоматизация врёт молча. Через месяц посчитайте разницу: сколько времени раньше уходило на переспрашивание задач и сколько уходит сейчас на проверку протокола. Начните со следующей планёрки: включите запись и попросите машину сделать протокол. Сравните с тем, что запомнили участники, — разница обычно отрезвляет. Как поставить это на поток, чтобы протокол собирался сам, — в бесплатном курсе для руководителей . Как это меняет ваши планёрки У вас изменится не только документооборот. Когда участники знают, что решения записываются с именами и сроками, они формулируют их точнее — и половина расплывчатых договорённостей исчезает сама. Ваш побочный выигрыш: вы перестаёте быть единственным человеком, который помнит, о чём договорились. Это освобождает вам голову лучше любого тайм-менеджмента. И назову вещь, которой не было в списке требований к руководителю ещё пять лет назад. Умение поставить машине задачу так, чтобы протокол собрался без вас, — это управленческий навык, ровно такой же, как умение провести саму планёрку. Руководитель, который держит договорённости в системе, стоит дороже руководителя, который держит их в голове: первого можно поставить на три отдела, второй упирается в объём собственной памяти. Осваивается это за один вечер на одной записи. Но пока вы его не освоили, вы конкурируете с теми, кто уже освоил. Попробуйте на ближайшей встрече — вам понадобится только запись и десять минут на проверку результата. Ваш первый протокол машина соберёт уже завтра — попробуйте.

## «Если бы я не пришёл, ничего бы не произошло»: внедрение автоматизации процессов без надзора
URL: https://davidgerstein.pro/blog/avtomatizatsiya-kotoraya-trebuet-nadzora/
Дата: 2026-07-25
Направление: Операционное управление
Цифры: 39 000 ₽/мес скрытого надзора, 10 автоматизированных процессов, 3 обязательных свойства
Коротко: Автоматизация, за которой нужно следить, — это вторая работа, а не автоматизация. В разборе на 10 процессах скрытый надзор съедает ≈39 000 ₽/мес (оценка), а процесс, который можно оставить без присмотра, обязан иметь 3 свойства: сам перезапускается после сбоя, сам сообщает о неудаче и отвечает на вопрос «жив?» за 10 секунд.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. У меня есть личный тест на настоящую автоматизацию, и я собираюсь им поделиться, потому что он экономит деньги ещё на этапе постановки задачи. Тест звучит так: что произойдёт, если про этот процесс все забудут на две недели? Если ответ «будет работать, а при сбое сам перезапустится или громко позовёт» — это автоматизация. Если ответ «надо будет поглядывать» — это не автоматизация. Это вторая работа, которую вы добавили к первой. Если вы узнаёте здесь свой вечер пятницы — «дай гляну, всё ли вышло», — дальше цифры, во что вам это обходится и что нужно требовать при внедрении. Внедрение автоматизации процессов: что заложить, чтобы не следить Если при внедрении автоматизации процессов не заложить три свойства — самоперезапуск, громкий сигнал о сбое и ответ на вопрос «жив?» за 10 секунд, — процесс придётся сопровождать руками до конца его жизни. На наборе из 10 автоматизированных процессов скрытый надзор — «глянуть, всё ли вышло», разобрать сбой, вспомнить проверить — обходится примерно в 39 000 ₽ в месяц (оценка) рабочего времени. Эти часы не попадают в расчёт окупаемости и съедают эффект. Процесс, который можно оставить без присмотра, обязан иметь три свойства: сам перезапускается, громко сообщает о сбое и отвечает на вопрос «жив?» за 10 секунд. Как я к этому пришёл История, после которой тест появился. Автоматическая публикация контента: процесс собирает материалы, готовит посты, выкладывает по расписанию. Работал прекрасно — пока однажды не упёрся в ошибку и молча не встал. Утром выясняется: ничего не вышло. Запускаю руками, чиню. Через неделю — то же самое, по другой причине. Фраза, которую я тогда сказал вслух: «Если бы я не пришёл и не проверил, ничего бы не произошло». В этой фразе — вся суть. Процесс формально автоматический, фактически — на ручном приводе, просто привод дёргается не каждый раз, а при сбоях. Но чтобы узнать о сбое, надо проверять. А чтобы проверять, надо помнить. А значит, задача не ушла из головы — она в ней поселилась в худшей форме: «не забыть проверить робота». Самое неприятное — что я узнавал о сбоях не по сигналу, а по отсутствию результата. Я заходил в канал по привычке, видел, что вчерашнего поста нет, и только тогда понимал: что-то сломалось ещё вчера, а значит, весь день процесс молчал впустую. Это и натолкнуло на формулировку теста: если единственный способ узнать о поломке — заметить пустоту там, где должен быть результат, надзор уже идёт, просто он не назван вслух. Арифметика, которую никто не считает Допустим, ручная задача занимала час в день. Автоматизация сократила его до нуля — но добавила: пять минут в день «глянуть, всё ли вышло», полчаса раз в неделю на разбор сбоя, и главное — фоновую ответственность, которая не делегируется. Если процессов таких не один, а десять (а их быстро становится десять), у вас появляется новая должность: смотритель зоопарка роботов. Обычно эта должность достаётся самому дорогому человеку в компании — тому, кто автоматизацию и заказывал. Именно поэтому «мы автоматизировали двадцать процессов» так часто соседствует с «почему-то никто не почувствовал облегчения»: автоматизируют то, что проще поддаётся, а не то, что держит поток. Отсюда и порядок действий — сначала описать процесс, найти узкое место и назначить владельца , и только потом отдавать шаг машине. Дальше — конкретные цифры на нашем наборе из 10 процессов, чтобы это перестало быть фигурой речи. Три свойства процесса, который можно оставить одного 1. Сам перезапускается Большинство сбоев — временные: сеть моргнула, сервис не ответил, файл пришёл битый. Процесс обязан уметь повторить попытку сам — с паузой, несколько раз, по одному конкретному упавшему элементу, а не всей пачке. Это решается при постановке задачи одной фразой в ТЗ и почти ничего не стоит. Добавленное потом — стоит дорого. 2. Громко зовёт, когда не справился Если перезапуск не помог — процесс сообщает туда, где сообщение увидят: в мессенджер ответственному, а не в лог-файл. Тишина должна означать «всё хорошо», и это соглашение важно держать честным: процесс, который молчит и когда работает, и когда умер, хуже процесса, которого нет, — он создаёт ложную уверенность. 3. Отвечает на вопрос «ты живой?» В любой момент за десять секунд можно узнать: когда процесс отработал в последний раз, что сделал, что в очереди. Не залезая в код и не спрашивая того, кто его писал. У меня это сводка одной командой или строка в ежедневном отчёте. Отдельный коварный случай — процесс, который «работает», но делает не то: у меня жил сборщик данных, который месяцами писал записи, при этом полезная часть молча не работала. Поэтому «живой» — это не «процесс запущен», а «результат сегодня существует и выглядит осмысленно». Правило Три свойства — перезапуск, громкий сбой, проверяемость — включаются в задачу на автоматизацию с первого дня. Автоматизация без них не принимается как готовая, сколько бы красиво она ни работала на демонстрации. Стоимость этих трёх свойств — процентов десять от проекта; стоимость их отсутствия — весь эффект проекта. Отличать автоматизацию от второй работы под тем же названием — управленческий навык, и нужен он вам до подписания задачи, а не после первого молчаливого сбоя. Три ошибки, которые сводят надзор на нет Даже когда за автоматизацию берутся всерьёз, надзор возвращается через одну из трёх типовых дыр: сигнал приходит не тому человеку, сигнал приходит слишком часто, или перезапуск маскирует проблему вместо того, чтобы её решать. Сигнал не тому человеку. Уведомление о сбое падает в общий чат отдела, где его читают все и не читает никто. Ответственность размывается: каждый думает, что отреагирует другой. Правильно — один конкретный получатель на процесс, даже если это неудобно признавать вслух: «за это отвечает N, и сообщение идёт лично N». Сигнал слишком частый. Если процесс присылает предупреждение при каждой мелочи — задержке на пять секунд, единичном таймауте, который перезапуск и так исправил, — люди быстро научаются игнорировать канал целиком. Через месяц там будет пятьдесят непрочитанных сообщений, и настоящий сбой утонет среди них. Сигнализировать нужно только о том, что требует действия человека, а не о любом отклонении от идеала. Перезапуск маскирует проблему. Процесс, который тихо перезапускается пять раз подряд и в итоге срабатывает, формально «жив» — но если он делает это каждый день, значит, где-то есть системная причина, которую никто не видит, потому что до открытого сбоя не доходит. У меня был именно такой случай с внешним сервисом, который отвечал через раз: процесс справлялся сам, отчёт был зелёный, а нагрузка на инфраструктуру росла месяцами, пока не вылилась в более дорогой сбой. Поэтому даже «успешные после перезапуска» случаи стоит один раз в неделю просматривать отдельно, а не считать полностью закрытым вопросом. Экономика надзора: во что обходится «просто поглядывать» В компании из 40 человек у нас 10 автоматизированных процессов; доработка недостающих свойств у 6 из них заняла ≈18 часов разовой работы, эксплуатация не добавила затрат — используются существующие каналы уведомлений, а эффект — снижение скрытого надзора с ≈39 000 ₽/мес до ≈2 000 ₽/мес, то есть чистая экономия ≈37 000 ₽/мес (оценка при ставке ~1 000 ₽/час). Один из этих 10 процессов — ежедневный отчёт для 8 менеджеров отдела продаж, которые в сумме закрывают около 50 сделок в месяц при обороте 9 млн ₽ и среднем чеке 180 тыс. ₽. Формально отчёт автоматический: цифры сами приходят в чат каждое утро. Фактически раз в одну-две недели он расходится с CRM на несколько сделок — обычно из-за тех, что двигают статус в выходные, — и тогда менеджеры по неделе работают по неверным цифрам, пока кто-то не заметит нестыковку и не поднимет её вручную. Это ровно третий тип из таблицы ниже: процесс работает, но требует регулярной проверки, потому что сам не умеет сказать «я соврал». Вторая категория из таблицы — процессы, которые уже умеют сигнализировать о явном сбое, но не умеют перезапускаться сами. У нас таких три, и по ним надзор — это не проверка «всё ли верно», а ручной перезапуск по сигналу: получил сообщение, зашёл, нажал кнопку. На каждый такой случай уходит 10–15 минут, но случаются они непредсказуемо, и именно эта непредсказуемость съедает управленческое внимание сильнее, чем сами минуты — переключение контекста стоит дороже, чем показывает секундомер. Категория процесса Кол-во из 10 Надзор, ч/мес Надзор, ₽/мес (оценка) Есть все 3 свойства — полностью автономные 4 0 0 Есть только громкий сигнал о сбое 3 12 12 000 Нет ни одного свойства — нужна ручная проверка 3 27 27 000 Итого 10 39 39 000 Полностью автономные — 40% Только сигнализируют — 30% Нужен ручной надзор — 30% Что мы не считаем эффектом: если сотрудник раньше тратил час в день на ручной шаг, а теперь тратит те же 39 часов в месяц на присмотр за автоматикой — это не экономия, а другая работа под старым названием. Экономией мы называем только то, что освобождается сверх текущего надзора после доработки — то есть разницу между 39 000 ₽/мес и 2 000 ₽/мес, а не разово выигранное время на старте проекта. Как я проверяю процессы: промпт для дежурного по автоматизациям Ежедневная ручная проверка 10 процессов занимает 15–20 минут в день; промпт ниже сводит это к чтению одной сводки, которую модель собирает из логов и вебхука Bitrix24 за 10–15 секунд, а не к обходу каждого процесса по отдельности. На входе — JSON со статусами процессов за сутки: часть данных приходит из вебхука Bitrix24 (например, статус фоновой синхронизации сделок), часть — из логов сервера, где крутятся публикация и отчёты. Модель должна не пересказать логи, а решить за меня один вопрос: нужно ли сегодня вмешаться руками. Пример ответа модели на этот вход: Ключевая деталь — поле action_needed . Пока оно есть и по нему честно можно ориентироваться, сводку можно читать по диагонали за 10 секунд, как и требует третье свойство. В день, когда сводка начинает врать («ok», хотя процесс не запускался неделю), доверие к ней рушится быстрее, чем строится, поэтому сам дежурный-промпт тоже раз в месяц стоит сверять руками с реальными логами — иначе он превращается в ещё один процесс, требующий надзора. Куда это масштабируется С ростом числа автоматических процессов появляется следующий уровень той же задачи: сторож сторожей — один ежедневный отчёт, который сводит состояние всех процессов в одну картину. У меня он приходит вечером в мессенджер и построен на том же принципе, что промпт выше: не «всё ли запущено», а «что реально требует моих рук сегодня». Это снимает последнюю форму надзора — необходимость помнить, за чем следить. На практике сторож сторожей — это тот же промпт, только на входе у него не три процесса, а десять, а на выходе — не построчный список, а один агрегированный вывод: сколько процессов зелёные, сколько требуют внимания, и есть ли среди них повторяющаяся причина сбоя за последние семь дней. Повторяющаяся причина — отдельный сигнал: если один и тот же процесс перезапускается по одной и той же ошибке третий день подряд, это уже не сбой, а системная проблема, которую перезапуск временно прячет, — ровно тот случай из раздела про типичные ошибки. Без сводного отчёта такую закономерность видно только задним числом, когда проблема успела вырасти. Тот же принцип «система должна следить за собой» относится и к данным, на которых всё построено, — про это отдельный разбор: как CRM тихо меняла данные задним числом , и почему без ежедневного снимка этого не видно. А про то, во что автоматизация обходится в деньгах в принципе, — разбор реальных расходов на ИИ . Чек-лист на понедельник Выпишите все автоматизированные процессы компании — обычно их оказывается больше, чем помнят вслух. Для каждого проверьте три свойства: сам перезапускается, сам сообщает о сбое, отвечает на «жив?» за 10 секунд. Посчитайте, сколько из них требуют регулярной ручной проверки (третья категория из таблицы) — это ваш реальный, а не декларируемый, объём надзора в часах. Переведите часы в деньги по ставке ~1 000 ₽/час и сравните с тем, сколько будет стоить доработка (в разборе — ≈18 часов разово на 6 процессов). Начните с процесса, чья цена ошибки выше всего — как отчёт для отдела продаж, который расходится с CRM молча. Ваш способ проверить, не попали ли вы в эту ловушку: посчитайте, сколько времени в неделю у вас уходит на присмотр за автоматикой. Если больше, чем экономит, — вы построили себе вторую работу. Посчитайте ваш надзор в часах за месяц и сравните с тем, что автоматика экономит. Если разница не в вашу пользу — либо доводите контур до конца, либо честно возвращайтесь к ручной работе: промежуточное состояние обходится дороже обоих вариантов.

## Узкое место в процессе: как найти то, что тормозит всю компанию
URL: https://davidgerstein.pro/blog/uzkie-mesta-v-processah/
Дата: 2026-07-12
Направление: Операционное управление
Цифры: разные выгрузки одного показателя расходятся почти в 5 раз · 7 → 52 канала связи за месяц · сотрудников больше, чем рабочих мест
Коротко: Узкое место в бизнесе редко находится там, где на него жалуются. Чтобы найти его, нужно спросить не «кто виноват», а где расходятся цифры, куда утекают деньги без контроля — в одной компании так обнаружили, что 45 из 52 оплачиваемых каналов связи, то есть почти 90%, никто не использовал — и какое звено физически не может обработать больше объёма. Дальше — автоматизация рутины и чёткие роли, а не новый штат.

Как найти узкое место в процессе Не искать виноватого, а задать процессу три вопроса: где расходятся цифры из разных источников, куда уходят деньги без привязки к результату и какое звено физически не тянет больший объём. В компании на 40 человек ответ нашёлся за вечер: 45 из 52 оплачиваемых каналов связи — почти 90% — не использовал никто, потому что за отключение лишнего не отвечал ни один человек. Проверка занимает неделю и не требует софта. Самый быстрый признак того, что узкое место в процессе у вас есть: одна и та же цифра из разных выгрузок не сходится — в одном офисе расхождение доходило почти до 5 раз . Участок, у которого нет своей цифры, и есть кандидат номер один. Если вы до сих пор ищете, кто именно тормозит работу, — вы ищете не то. Узкое место в процессе почти никогда не совпадает с участком, на который жалуются: жалуется тот, кому больно, а рвётся там, куда никто не смотрит. Разбираю метод, который находит его за вечер, вместо месяцев интуитивных догадок. Полный маршрут — от описания процесса до автоматизации — в руководстве «Как управлять бизнес-процессами» . В апреле компания платила за несколько каналов связи. В мае — уже в разы больше при том же штате. На каждого сотрудника подключены и WhatsApp, и Telegram, хотя фактически столько каналов на человека не нужно. Руководитель посмотрела на список и сказала прямо: столько сотрудников, чтобы это использовать, в компании нет. Если считать грубо: 45 из 52 каналов — «лишние», то есть почти 90% всех подключений компания оплачивала просто так (оценка, точное число нужных каналов не считали). Формула для своего случая простая: (число оплачиваемых каналов на сотрудника минус фактически нужное) × стоимость одного канала = переплата в процентах от бюджета на связь. Никто не отключал ненужное, потому что за это не отвечал ни один конкретный человек. Это и есть узкое место в бизнесе: расход, за который никто не отвечает, пока кто-то не задаст правильный вопрос. Это типичная картина узкого места: деньги или время утекают не там, где на это жалуются. Финансовый сотрудник месяцами жаловался, что его дёргают по любому платежу — срочно, сейчас, пожалуйста. Он не успевал с основной работой и начал сомневаться в своей компетентности. Руководитель разбирался неделю и нашёл проблему не в человеке, а в расписании: в его дне не было выделенного часа для платежей. Ввели правило — обработка оплат с 10 до 11 — и перебивания прекратились сами. Вот так обычно и выглядит поиск узкого места: то, на что жалуются, почти никогда не является причиной. Три вопроса, которые находят узкое место в процессе Задайте их себе по любому своему процессу — и вы сузите поиск с «где-то в компании» до конкретного участка за час. Гадать бесполезно. Работают три конкретных вопроса, которые я задаю по очереди на каждом уровне — от отдела до конкретного сотрудника. Где расходятся цифры из разных источников — если два человека называют разные числа по одному и тому же показателю, там дыра. Куда уходят деньги без привязки к результату — подписки, инструменты, часы, которые никто не пересчитывал последние полгода. Какое звено физически не может принять больше объёма — не потому что люди плохие, а потому что пропускная способность исчерпана. Дальше по каждому из трёх пунктов — реальные кейсы, а после них — механика, которую можно повторить у себя за неделю. Узкое место в процессе — это структура, а не человек Если ваш ответ на вопрос «где тормозит» звучит как имя сотрудника — проверьте ещё раз. Обычно человек стоит в точке, куда сходятся три процесса, и справился бы кто угодно так же. История с финансистом — частный случай общей ошибки: искать виноватого там, где на самом деле не хватает организации дня. Похожая история была с руководителем маркетинга — он тратил колоссальное время на ручное заполнение отчётов, счетов и таблиц в разных местах. Даже отправку счёта приходилось перепроверять через почту — точно ли ушло. Его слова: «Я бы хотел погружённо работать — взял задачу, погрузился, час ей занимался. А в большинстве случаев если удалось поделать 15 минут — это уже невероятная удача». 15 минут концентрации — вот реальная метрика узкого места. Не «сотрудник не справляется», а «структура дня физически не даёт сосредоточиться». Назову вещь своим именем: читать процесс по цифрам, а не по жалобам — это отдельный управленческий навык, и его придётся освоить. Навык руководителя сегодня не в том, чтобы раздать задачи и спросить результат, а в том, чтобы увидеть за жалобой конструкцию: где сходятся потоки, где нет ответственного, где звено упёрлось в потолок пропускной способности. Я сам полгода искал виноватых вместо того, чтобы мерить, — и это самая дорогая моя ошибка в операционке. Руководитель, который умеет разбирать процесс на звенья, стоит дороже того, кто умеет только требовать. Делегирование — это не «дать ещё рук» Отдельная категория узких мест — там, где руководитель путает делегирование с ручным трудом. Пример: менеджер ведёт несколько проектов, в каждом по несколько треков. Ему не нужна ещё одна пара рук — ему нужен помощник на каждый проект. Проблема тут не в возможности масштабирования, а в отсутствии у самого менеджера навыка ставить задачи. Дать ему одного помощника — не решить узкое место, а размазать его на двоих. Правило Если жалоба звучит «не успеваю» — сначала проверь структуру дня и распределение ролей, и только потом нанимай людей. Лишний человек в неправильной структуре создаёт второе узкое место вместо решения первого. Деньги утекают там, где вы не считаете Простое правило: если у участка нет цифры, он и есть ваш главный кандидат в узкие места. Второй вопрос метода — куда уходят деньги без привязки к результату. История с каналами связи выше — не разовая ошибка бухгалтерии, а симптом отсутствия аудита подписок. Инструменты подключаются по запросу «нужно срочно», а отключаются никогда, потому что за это не отвечает ни один конкретный человек. С деньгами работает тот же принцип, что и с расписанием, — только вместо часа в дне тут лишняя строчка в счёте. Разработчик использовал дорогую модель (уровня Opus) для задач, которые дешёвая версия (уровня Sonnet) решала с идентичным результатом. Проверили на одном и том же промпте — разницы в качестве не нашли, а разница в цене за токен была ощутимой: по открытым прайсам топовые модели обычно в 5-10 раз дороже «мини»-версий на сопоставимых задачах извлечения и структурирования текста (оценка по публичным тарифам, не внутренние цифры компании). Инструмент подключили «на всякий случай» и забыли проверить, нужен ли он в такой конфигурации — почти дословно та же история, что и с каналами связи. Данные, которые говорят на разных языках Проверьте у себя: одинаково ли называются одни и те же вещи в вашей CRM, учёте и отчётах руководителей. Третий диагностический вопрос — попробовать выгрузить одну и ту же цифру из разных мест. В одном региональном офисе попытались выгрузить список клиентов из воронки — получили три разных результата, расходящиеся почти в пять раз. Это не ошибка одного отчёта, это следствие децентрализованного хранения данных: у каждого своя версия правды, и никто не может сказать, какая верная. Именно с этого симптома обычно и начинается разговор о том, что CRM врёт — я подробно писал, как поймать систему на сдвиге дат и что делать, если данным нельзя доверять, в статье про Битрикс24 . Симптом Что на самом деле сломано Сотрудника постоянно перебивают Нет структуры рабочего дня Один человек «не тянет» несколько проектов Отсутствует навык постановки задач, а не рук не хватает Счёт «в разработке», а по факту потерян Нет единой точки истины по статусам Разные выгрузки дают разные цифры Децентрализованное хранение данных Растущий счёт за подписки без роста штата Нет ответственного за аудит инструментов Когда процесс упирается в стены Бывает и так, что ваше узкое место — не в данных, а в реальном мире: помещение, оборудование, физическая пропускная способность. Иногда узкое место — не про людей и не про цифры, а буквально про метры. В компании сотрудников по списку заметно больше, чем реальных рабочих мест в офисе: большая часть в основном помещении, остальные распределены по паре отделов, плюс ресепшен. При планируемом росте штата — запуск нового рынка, новый отдел — офис физически не вмещает коллектив. Никакая CRM и никакой ИИ это не решит, пока не пересчитаны квадратные метры. Мест в офисе сейчас меньше нужного Сотрудников по списку больше мест После найма (план) разрыв растёт На диаграмме — разрыв между доступными местами и сотрудниками по списку, который после планового найма ещё увеличится. В другом случае ту же проблему решили без стройки: переставили столы напротив друг друга, оптимизировали проходы — и разместили заметно больше людей на меньшей площади, чем изначально планировалось. Иногда узкое место снимается не бюджетом, а перекладкой мебели. Для контраста: в этой же компании параллельно обсуждался капитальный ремонт другого помещения — смета вышла на сумму, сопоставимую с несколькими месячными бюджетами компании, при сроке в полгода и отдельной ежемесячной компенсацией подрядчику за координацию. Это не альтернатива перестановке столов — это совсем другой класс решения для совсем другого масштаба задачи, и путать их — типовая ошибка: сначала стоит проверить дешёвый вариант (мебель, перепланировка проходов), и только если он физически не закрывает потребность — переходить к капитальным затратам. Та же нехватка пропускной способности — только в отделе документооборота. За один день менеджеры провели несколько встреч и получили много лидов, но сами договоры не готовят — это делают два специалиста, которые уже работают на износ, включая выходные. Проблема не в том, что менеджеры плохо продают. Проблема в том, что звено дальше по цепочке физически не успевает за новым потоком. Пока это не решено, увеличивать продажи бессмысленно — деньги всё равно упрутся в очередь на оформление. Оценить масштаб риска можно той же формулой, что и для воронки ниже: количество договоров в очереди × средний чек = сумма, которая физически не может быть закрыта в срок. Подробнее о том, как теряются деньги между маркетингом и продажами, я разбирал в материале про лиды без продаж . Механика: как провести диагностику за неделю Три вопроса выше — это направление поиска. Ниже — последовательность действий, которую можно повторить с любой командой без специального софта в первую неделю. День 1-2. Сбор жалоб. Что → фразы сотрудников на планёрках и в личных разговорах («не успеваю», «опять переделывать», «где взять цифру»). Чем → простой список без анализа. Куда → одна таблица на всех, колонки «кто сказал», «про что», «дата». День 2-3. Кросс-выгрузка данных. Что → один и тот же показатель (число клиентов в воронке, сумма дебиторки, конверсия) выгружается из CRM, из отчёта аналитика и из ручной таблицы менеджера. Чем → штатные фильтры системы, без доработок. Куда → сравнительная таблица с тремя колонками и расхождением в процентах. День 3-4. Аудит расходов на инструменты. Что → счета за подписки и коммуникационные каналы за последние 2 месяца. Чем → выгрузка из платёжной системы или бухгалтерии. Куда → список «инструмент — стоимость — кто реально пользуется» с пометкой «оставить/отключить». День 4-5. Замер пропускной способности узких звеньев. Что → количество задач на входе и на выходе у звена, на которое жалуются чаще всего (документооборот, согласование, поддержка). Чем → ручной подсчёт за 2-3 дня или счётчик в боте. Куда → таблица «поступило / обработано / в очереди». День 5. Синтез. Кто → руководитель направления вместе с тем, кто вёл таблицы. Что делает → сопоставляет три вопроса метода с собранными данными и выбирает 1-2 узких места с наибольшим денежным весом. Куда → короткая дорожная карта на ближайший месяц, а не список из двадцати пунктов. Пример того, как выглядит выбор на шаге «Синтез» в реальности. По итогам недели на столе оказалось два кандидата: сильное расхождение выгрузок по числу клиентов в одном офисе и очередь на оформление договоров у двух специалистов, работающих по выходным. Формально оба «узкие места». Но у расхождения данных цена ошибки — потерянное время на споры, чья цифра верна, это часы аналитика в неделю. У очереди на договоры цена ошибки — упущенные сделки, которые физически не закрываются в срок, то есть выручка. Руководитель в этом случае выбрал вторым приоритетом именно очередь на оформление: она напрямую сокращает деньги, а не только время. Расхождение выгрузок ушло в план на следующий месяц с более простым решением — одна точка истины по статусу клиента вместо трёх таблиц. Правило простое: при прочих равных сначала закрывается узкое место, которое режет выручку, а не то, которое просто раздражает. ИИ-связка: как автоматизировать сбор сигналов об узких местах Ручной сбор жалоб и дорожных карт хорошо работает один раз, но быстро выдыхается, если делать это каждый квартал заново. Рабочий вариант — превратить голосовую рефлексию менеджера в структурированные данные автоматически. Это тот же принцип, что применили в компании для дорожной карты изменений: менеджер за полчаса голосом описывает по каждой стадии воронки, что есть сейчас, что работает, что нужно чинить — и это уходит техническому специалисту на расписание автоматизаций. Конвейер: голосовое сообщение в Telegram-бот → транскрибация → структурирование моделью по шаблону → запись в Google Sheets → уведомление руководителю с приоритетами. Модель на шаге структурирования — дешёвая (уровня Sonnet или аналогичного класса «мини»), а не топовая. Задача здесь — не творческая генерация, а извлечение сущностей по жёсткому шаблону: разработчик в этой же компании проверял ровно это на одном промпте с дорогой и с дешёвой моделью — результат был идентичным, а счёт за токены — разным. Пример ответа модели на реальный кусок расшифровки про подготовку договоров: Инженерная обвязка. Хранилище — лист Google Sheets «Дорожная карта», каждая строка — один ответ по одному этапу. Триггер — Telegram-бот принимает голосовое, отправляет на транскрибацию, скрипт (Google Apps Script или n8n) формирует JSON из шаблона выше и вызывает API модели. Результат пишется обратно в таблицу и дублируется в Telegram-чат руководителя со scoring по приоритету — тот же принцип, что применили для ежедневной сводки по задачам и встречам. Стоимость вызовов модели логируется отдельным столбцом — чтобы не повторить историю с дорогой моделью там, где хватает дешёвой. Если транскрипция пустая или модель вернула невалидный JSON — строка помечается статусом «ошибка», и в отдельный технический чат уходит алерт с минимумом контекста, достаточным, чтобы разработчик не открывал таблицу вручную: Ответственный получает этот алерт в личном или групповом техническом чате, нажимает кнопку в боте — и скрипт заново прогоняет ту же расшифровку через модель без ручного копирования текста. Без такого алерта ошибки обработки просто накапливаются в таблице незамеченными, и через месяц половина дорожной карты оказывается пустой — это тот же тип узкого места, что и с каналами связи: расход или сбой, за который никто не отвечает. Google Sheets — Дорожная карта 20-30 голосовых в день ≈1000 токенов за вызов 5 приоритет: критично Этап Что автоматизировать Приоритет Статус Оформление договора Автозаполнение полей из CRM, уведомление о просрочке 5 критично Прикинуть стоимость эксплуатации можно так: один голосовой отчёт менеджера — это примерно 300-500 слов расшифровки, то есть около 700-900 токенов на вход плюс промпт, и ещё около 150-200 токенов на ответ модели — итого порядка 1000 токенов за вызов (оценка). При потоке в 20-30 сообщений в день это 20 000-30 000 токенов в день, или 600 000-900 000 токенов в месяц. На дешёвой модели это укладывается в единицы долларов в месяц (оценка по порядку публичных тарифов), плюс сопоставимые копейки за транскрибацию голоса. Формула для своего случая: количество сообщений в день × токены на вызов × цена за токен × дни в месяце = месячный счёт за модель. Экономика: что стоит найти узкое место и что это даёт Диагностика по трём вопросам почти ничего не стоит — это часы руководителя и аналитика на сбор данных. Стоит автоматизация конвейера вокруг неё. Ниже — расчёт по фрагментам, которые я намеренно не смешиваю в один общий эффект: это разные узкие места, с разной механикой экономии, и складывать их в одну итоговую сумму было бы натяжкой. Статья Часы / объём Оценка масштаба Настройка бота и скрипта для дорожной карты (разово) 8-12 часов работы разработчика меньше двух рабочих дней одного специалиста — разовые трудозатраты Эксплуатация: транскрибация + вызовы дешёвой модели 20-30 сообщений в день, ≈1000 токенов на вызов на порядок дешевле часа работы специалиста в месяц (единицы долларов, оценка по публичным тарифам) Высвобождение времени аналитика на ручном отчёте ≈30 минут в день → 10,5 часа в месяц (факт из практики) ≈1,5 рабочего дня в месяц на одного сотрудника — время, освобождённое для другой работы Переплата за незакрытые каналы связи (факт: 7→52 канала) 45 «лишних» каналов из 52 переплата, в 45 раз превышающая стоимость одного подключения — почти 90% всех оплаченных каналов Формула для строки с аналитиком, если хотите прикинуть свой случай: минуты экономии в день × 30 дней ÷ 60 = часы экономии в месяц. Здесь 30 минут × 30 ÷ 60 = 10,5 часа — это чуть больше рабочего дня, который каждый месяц высвобождается на одного сотрудника для другой работы. При типичной ставке менеджера это условная стоимость освобождённого времени, сопоставимая с четвертью недельного дохода на одного сотрудника — не «живые» деньги в кассе, а часы, которые можно направить на аналитику вместо копирования цифр. Отдельно — иллюстративный пример того, во сколько обходится расхождение данных, если его не замечать. Отдел из нескольких менеджеров, каждый ведёт около 10 сделок в месяц со средним чеком, сопоставимым с несколькими месячными окладами специалиста — в сумме десятки сделок в воронке. Если из-за нестыковки данных между источниками (как в примере с расходящимися выгрузками по числу клиентов) около 10% сделок «зависает» и выпадает из поля зрения — это несколько сделок, которые никто не сопровождает вовремя, потому что в отчётах их как будто нет. При типичном среднем чеке это риск, сопоставимый с месячным фондом оплаты труда небольшого отдела, которые компания не обязательно теряет физически, но которыми не управляет — сделки просто зависают между версиями правды, пока кто-то вручную не сверит три таблицы (оценка, консервативный расчёт по условному отделу, не факт из практики конкретной компании). Это не сумма, которую можно сложить с переплатой за каналы связи или с высвобожденным временем аналитика — три разных узких места, три разных источника риска, и путать их в один «эффект от ИИ» было бы нечестно перед читателем. Чек-лист на понедельник Если начинать прямо сейчас, без предварительной подготовки — вот пять действий, которые можно закрыть за один рабочий день. Выпишите три фразы-жалобы, которые слышали от разных людей за последний месяц, и отметьте, совпадают ли они по сути. Запросите один и тот же показатель (число клиентов, сумма к оплате, конверсия) из двух-трёх источников и сравните цифры. Поднимите счета за инструменты и подписки за последние два месяца — отметьте те, что выросли без роста штата. Найдите звено, на которое чаще всего жалуются менеджеры или клиенты, и посчитайте вручную его вход и выход за два дня. Выберите одно узкое место с наибольшим денежным весом и назначьте по нему одного ответственного, а не рабочую группу. Метод не требует новых людей и дорогого софта — требует готовности задать три вопроса вместо того, чтобы искать виноватого. Дальше, когда узкое место найдено, автоматизация вроде конвейера из голосового сообщения в структурированную дорожную карту убирает рутину вокруг диагностики — но не заменяет саму диагностику. Про то, как автоматизация без надзора превращается в новую проблему, я писал отдельно в материале про автоматизацию, требующую контроля . Как автоматизировать поиск и следить за узкими местами постоянно — в бесплатном курсе для руководителей . Ваш замер на эту неделю: один процесс, время каждого шага по факту. Узкое место обнаружится само, и почти наверняка это будет не тот участок, на который жалуются ваши люди. Именно поэтому мерить нужно, а не спрашивать. Как это применить у себя Ваш порядок действий такой. Возьмите процесс, на который у вас больше всего жалоб. Разложите его на шаги — не по регламенту, а как есть на самом деле. По каждому шагу узнайте у ваших людей, сколько времени он занимает и чего они ждут дольше всего. Дальше вы увидите картину: у вас будет один шаг, где очередь, и несколько, где вам казалось, что проблема. Разница между вашими ощущениями и замером обычно и есть самое ценное в этом упражнении. И не пытайтесь чинить всё сразу: расшив одно узкое место, вы получите новое в другом месте — это нормально, и это ваша следующая задача. Начните этот замер на своём процессе на этой неделе — как соединить его с постоянным мониторингом, разбираю в бесплатном курсе для руководителей . У нас первый такой замер показал, что мы полгода чинили не то: жаловались на отдел продаж, а очередь стояла на согласовании договоров. Я тогда извинился перед руководителем продаж — и с тех пор мы не обсуждаем узкие места без цифр.

## Регламент работы отдела: от полки к инструменту
URL: https://davidgerstein.pro/blog/reglamenty-kotorye-rabotayut/
Дата: 2026-06-21
Направление: Операционное управление
Цифры: потери без регламента различаются в разных сценариях на порядок
Коротко: Регламент работы отдела начинает работать только тогда, когда описывает расписание дня и конкретное повторяющееся действие, а не абстрактную обязанность. Рабочий регламент закрепляется после того, как сотрудник трижды сделал задачу правильно — по формуле «неправильно — неправильно — правильно». Отсутствие такого правила стоит компании от 22 000 ₽ до 900 000 ₽ в месяц в зависимости от масштаба сбоя (оценка).

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Сколько регламентов написано в вашей компании и сколько из них выполняется? Разница между этими числами — цена вашей работы по наведению порядка, которая ушла в стол. Регламент не работает не потому, что люди плохие. Он не работает, потому что написан для проверяющего, а не для исполнителя: длинный, общий и не отвечающий на вопрос «что делать в четверг в три часа». Финансовый сотрудник компании жаловался, что не успевает с основной работой. Коллеги дёргали его весь день — срочные оплаты, вопросы по счетам, «а вы уже перевели?». Он начал сомневаться в собственной компетентности. Руководитель разбирался не с человеком, а с расписанием: в рабочем дне не было выделенного окна на платежи. Ввели правило: обработка оплат — с 10 до 11, всё остальное время закрыто для таких вопросов. Проблема исчезла не потому, что сотрудник стал работать быстрее, а потому что в компании наконец появился регламент, которого раньше не существовало вообще — только ощущение, что «все всё знают». Цену такого отсутствия регламента посчитать просто: часы отвлечения в день × ставка за час × число рабочих дней в месяце = потери в месяц. Если сотрудник тратит условно час в день на реакцию на чужие срочные вопросы вместо плановой работы, при ставке ~1000 ₽/час (оценка) и 22 рабочих днях в месяце это даёт около 22 000 ₽ потерь рабочего времени одного человека в месяц (оценка). При этом закрыть проблему часто можно не наймом второго специалиста, а одним правилом в календаре. Как составить регламент работы отдела, который будут соблюдать Регламент работы отдела соблюдают, когда он привязан к конкретному времени или точке в процессе и описывает одно повторяющееся действие, а не обязанность вообще. Закрепляется он не с первого раза: рабочая формула — три итерации, «неправильно — неправильно — правильно», и только после третьей удачной попытки действие фиксируют инструкцией. Пока правила нет, компания платит за него временем и выручкой. Час отвлечений в день на одном сотруднике при ставке ~1000 ₽/час и 22 рабочих днях — около 22 000 ₽ в месяц (оценка). В документообороте счёт другой: 10% сделок, зависших из-за отсутствия правила очерёдности, в отделе с оборотом 9 млн ₽ дают риск ≈900 000 ₽ в месяц (оценка). Почему документ не работает без расписания Мы написали десятки регламентов, прежде чем я понял простую вещь: документ без встроенной проверки — это пожелание. Никто не саботирует, просто у всех есть работа поважнее, чем помнить, что там написано. Кейс с финансистом — частный случай общей проблемы: у большинства перегруженных сотрудников нет не задач, а структуры дня. Задачи прилетают асинхронно, каждый коллега считает свой запрос срочным, и человек весь день переключается между чужими приоритетами вместо своих. Формально должностная инструкция у него есть. Реально — нет ни одного протокола, который бы говорил: «в это время — вот это, в остальное — недоступен». То же самое звучит в жалобе руководителя маркетинга, который тратит колоссальное время на ручное заполнение отчётов и таблиц в разных местах и не может выделить час на аналитику без переключений: «Я бы хотел погружённо работать: взял задачу, погрузился, час ей занимался. А в большинстве случаев, если 15 минут удалось поработать — это невероятная удача». Проблема здесь не в мотивации и не в компетенциях. Проблема в отсутствии регламента, который бы защищал время на глубокую работу так же, как защищает окно 10–11 у финансиста. Правило Регламент, который не привязан к конкретному времени и не защищает конкретный блок в календаре, остаётся декларацией. Работает только то расписание, которое коллеги физически не могут нарушить, потому что окно закрыто в системе или объявлено вслух при всех. Механика: от сбоя до инструкции Ваш ориентир: новый человек должен сделать правильно, не спрашивая никого. Если для выполнения нужны устные пояснения — регламент не готов. В одной из компаний разложили появление регламента на понятную последовательность действий. Дальше — шесть шагов, которые можно повторить с любой командой. Фиксация сбоя. Руководитель или сам сотрудник замечает повторяющуюся проблему — перебивания, разные цифры в отчётах, зависшую задачу. Источник — жалоба, наблюдение на планёрке, разбор конкретного провала. Первая попытка действия без инструкции. Сотрудник выполняет задачу как умеет. Результат почти всегда неидеальный — это ожидаемо, а не повод для штрафа. Фиксация действия. Каждое новое действие либо документируется текстом, либо записывается на диктофон для расшифровки. Формат неважен — важно, что попытка не исчезает бесследно. Повторение и разбор ошибок. Формула трёх итераций: неправильно — неправильно — правильно. После третьего раза, когда результат устраивает, действие проверяют ещё раз на воспроизводимость. Закрепление инструкцией. Если третья попытка сработала — действие фиксируют как регламент и не проверяют его вручную каждый раз заново. Дальше его соблюдение можно передать на автоматическую проверку. Точка контроля. Кто-то — руководитель, проект-менеджер, бот — периодически сверяет, что регламент всё ещё выполняется так, как закреплён, а не «как удобнее сегодня». Формула трёх итераций работает, потому что она не пытается угадать идеальный процесс заранее. Она фиксирует то, что реально произошло, и делает это правилом. Заранее написанная инструкция почти всегда описывает идеальный процесс, которого не существует. Когда данные и роли расходятся У нас был случай, когда регламент требовал заполнять поле, которого в системе уже не существовало. Полгода люди честно пытались его найти и тихо считали документ бредом — и были правы. Самая наглядная иллюстрация отсутствия стандартизации — попытка выгрузить список клиентов одного региона из системы и получить три разных числа. Общий фильтр по региону 80 Фильтр менеджера А 22 Фильтр менеджера Б 17 На диаграмме — три результата одной и той же выгрузки клиентов одного региона: они расходятся почти в четыре раза. Это не ошибка одного сотрудника — это следствие того, что данные хранятся вразнобой: разные фильтры, разные представления воронки, разные привычки у разных менеджеров. Регламента «как считать клиентов» просто не существовало, поэтому каждый посчитал по-своему, и все три ответа были по-своему правильными для того, кто их получил. О том, как система хранения данных сама по себе может искажать цифры ещё до того, как их кто-то посчитал вручную, я разбирал в статье про сдвиг дат в Битрикс24 . Похожая история — с производственным циклом в консультационном бизнесе. Компания разделила процесс на два блока: «Производство» (интервью, сбор документов, структура) и «Упаковка» (редактура, вёрстка, согласование, финальный выпуск). За оба блока отвечает один проект-менеджер, но подрядчики и сроки — разные. Персональный менеджер работает лицом к клиенту, проект-менеджер отвечает за качество продукта. Это и есть стандартизация: не единая инструкция «на всё», а чёткая граница между двумя ролями с разной ответственностью. Без регламента С регламентом Финансист прерывается весь день, не успевает с основной работой Окно 10–11 закрыто для платежей, остальное время — на основные задачи Три выгрузки клиентов дают три разных числа Единый источник данных и единый способ подсчёта Действие делают заново каждый раз с нуля После трёх итераций действие закреплено инструкцией и не пересматривается вручную Один человек одновременно обучает новичков и ведёт опытных продавцов Роли разделены: один занимается только стажёрами, другой — менеджерами Разделение ролей встречается и в отделе продаж: попытка масштабировать команду через групповой набор стажёров провалилась, потому что менеджер не мог одновременно обучать новичков и управлять опытными продавцами. Решение оказалось не в найме ещё одного менеджера «вообще», а в разделении зон ответственности: обучение — отдельная роль, управление опытной командой — отдельная. Это тоже регламент, просто выраженный не текстом, а структурой должностей. Где регламент подменяют профилем личности Обратный пример — компания долго не могла сформулировать требования к новой ключевой роли, продакшн-менеджеру для запуска проекта. Обсуждение шло больше часа: разбирали личные качества кандидатов, но так и не сформулировали, что конкретно человек будет делать на этой должности. Если обсуждение вакансии сводится к «нам нужен инициативный, ответственный человек», а не к перечню операций и точек контроля, регламента для этой роли не появится вообще — ни на бумаге, ни в реальности. Ошибка воспроизводится потом на каждом собеседовании и каждой аттестации, потому что сравнивать не с чем. ИИ-связка: проверка соблюдения без ручного контроля Здесь вы получаете то, ради чего всё затевалось: регламент начинает проверяться сам, а вам приходит список отклонений, а не ощущение, что «кажется, не соблюдают». Ручная проверка регламентов — та же проблема, что и ручное заполнение отчётов: она съедает время того, кто мог бы заниматься содержательной работой. В одной из команд её решили так же, как проверку контента: автор загружает документ на Google Диск, триггер запускает скрипт, отчёт о соответствии приходит в Telegram. Теперь не нужно вручную перечитывать многостраничные документы ради формальных пунктов. Логика переносится на регламенты почти без изменений. Схема конвейера: Google Диск (папка «Регламенты на проверку») → триггер Apps Script → запрос к модели с текстом документа и чек-листом → результат в Google Таблицу и Telegram-чат ответственного → раз в неделю руководитель просматривает сводку отклонений. Для этой задачи не нужна дорогая модель. В одной из команд заметили, что дорогая модель (Opus) и более дешёвая (Sonnet) дали идентичный результат на одном и том же промпте — разница была только в цене токенов. Проверка регламента по чек-листу — задача классификации, а не творческого рассуждения, поэтому дешёвая модель здесь справляется так же надёжно. Прикинуть свою экономию можно так: число проверяемых документов в месяц × разница в цене токенов между моделями на один прогон = экономия в месяц. Если прогонять несколько десятков регламентов в месяц, а разница в цене между дорогой и дешёвой моделью на один прогон невелика (оценка, зависит от длины документа), суммарная экономия на токенах будет скромной. Основной эффект здесь не в деньгах на токены, а в том, что дешёвую модель не жалко гонять чаще и по большему числу документов. На практике здесь достаточно модели уровня Sonnet или GPT-4o-mini — при регулярных проверках экономия на токенах ощутима именно за счёт объёма, а качество результата не проседает. Пример ответа модели на реальный документ с пропущенной точкой контроля: Инженерная обвязка. Скрипт крутится на Google Apps Script, привязан к папке на Google Диске, срабатывает по событию добавления или изменения файла. Результат пишется в Google Таблицу (журнал проверок по датам) и дублируется сообщением в Telegram-чат ответственного за регламент. Если вызов модели падает — таймаут или лимит квоты — файл помечается тегом «ошибка проверки», в Telegram уходит текст ошибки, повторный запуск можно поставить по расписанию раз в час или запускать вручную кнопкой в таблице. Никакой самостоятельной эскалации бот не делает — решение о доработке документа всегда принимает человек. Telegram · Журнал проверки регламентов неск. десятков документов в месяц Документ Статус Замечание Регламент оплаты счетов не пройдено нет точки контроля Регламент выгрузки клиентов пройдено — Регламент подбора менеджеров пройдено — Ограничение ИИ-проверки Модель хорошо ловит формальные пропуски — нет срока, нет ответственного, нет измеримого результата. Она плохо оценивает, решает ли регламент реальную проблему клиента или сотрудника. Итоговую приёмку регламента должен делать человек, знающий контекст процесса, а не только чек-лист. Где регламент работы отдела ломается на стыке Главный разрыв — между тем, кто пишет документ, и тем, кто по нему работает. Проверьте у себя: писал ли ваш регламент человек, который сам делает эту работу? Показательный провал — разработка портала на базе большого массива вопросов (несколько сотен тысяч). Один специалист собрал контент и дизайн, передал техлидеру — и тот неделю не мог собрать систему нормально. Результат описали так: «красивый дом, но дверей нету, как зайти непонятно». Причина не в квалификации техлидера, а в отсутствии чёткого технического задания — регламента передачи задачи между контентной и технической частью команды. Каждый сделал свою часть хорошо, но регламента стыковки не было, поэтому проект не собрался. Такой же разрыв, только на уровне управления, — ситуация, когда руководителя разработки не подключали к планёркам по внедрению ботов и автоматизации, хотя эти решения напрямую касались его работы. Собственник признал это управленческой ошибкой и вернул руководителя в контур обсуждений. Регламент коммуникации между отделами — кто на каких встречах обязан присутствовать — такая же часть стандартизации процессов, как инструкция для рядового сотрудника. Где ломается Регламент, написанный одним отделом для другого без участия исполнителя, почти всегда упирается в разрыв на стыке. Дизайн и контент можно сделать отдельно, но правило передачи между этапами нужно писать вместе с тем, кто будет собирать финальный результат. О том, как автоматизация превращает часть подобных регламентов в фоновый процесс без ручного контроля, я писал в статье про протоколы планёрок, которые документируют себя сами . А про то, как выстраивается многоуровневая структура ответственности — от стратегии компании до задач конкретного сотрудника, — в материале про стратегию как рабочий инструмент . Экономика: что вам это стоит и что даёт Ваши затраты — часы на описание. Отдача — время, которое вы перестаёте тратить на объяснения одного и того же новым людям. Стоимость внедрения одного формального регламента невысокая: 1–2 часа на разбор сбоя и формулировку правила, ещё 1–2 часа на настройку автоматической проверки, если она нужна. Основные затраты — не деньги, а дисциплина: кто-то должен зафиксировать первую попытку, разобрать три итерации и довести дело до закреплённой инструкции. Отдельно считается цена отсутствия регламента — там, где есть конкретные цифры из практики. Общая логика одна: время потерь в день × ставка часа × число рабочих дней в месяце = потери в месяц (оценка); ставку и часы потерь стоит подставлять свои, взяв консервативную оценку. Ситуация Потери без регламента (оценка) Эффект после внедрения Ручной ежедневный отчёт (30 мин/день на сотруднике) ≈11 000 ₽ в месяц на одного сотрудника (0,5 ч × 22 дня × 1000 ₽/час) Данные тянутся из CRM автоматически, время идёт на анализ Поиск «правильной» цифры из трёх версий выгрузки ≈22 000 ₽ в месяц на одного сотрудника (1 ч в день × 22 дня × 1000 ₽/час) Единый регламент подсчёта, сверка не нужна Несогласованные подключения мессенджеров на сотрудника рост затрат на связь ≈30 000 ₽ в месяц (оценка, расчёт ниже) Аудит и лимит на подключение новых каналов каналы в апреле каналы в мае На диаграмме — рост числа оплаченных коммуникационных каналов на команду в несколько раз за месяц, при почти неизменном числе реальных пользователей. Последняя строка таблицы — отдельный сюжет: за месяц число оплаченных коммуникационных каналов на условной команде выросло с 10 до 30, хотя число сотрудников, которые реально ими пользовались, за это время почти не изменилось. При типичной цене подписки на канал (WhatsApp или Telegram-номер с интеграцией в CRM) ~1500 ₽/мес формула простая: число каналов × цена канала = месячные затраты на связь. Было 10 × 1500 = 15 000 ₽, стало 30 × 1500 = 45 000 ₽, прирост — 30 000 ₽ в месяц (оценка). Это треть условного оклада линейного сотрудника поддержки в этой компании (90 000 ₽), при том что реальных пользователей почти не прибавилось. Причина — не злой умысел, а отсутствие регламента: подключение нового канала не требовало согласования, поэтому каждый добавлял себе WhatsApp и Telegram по мере желания. Такой риск не виден в моменте — он всплывает только на аудите. Более крупный пример — из документооборота. Два специалиста, готовящие договоры, работают на износ, включая выходные, потому что менеджеры сами не готовят документы, а поток лидов растёт. Формула для своего случая: число менеджеров × доля зависших из-за документов сделок × средний чек = потери выручки в месяц. Если взять условный отдел из 6 менеджеров с оборотом ~9 млн ₽/мес и средним чеком 150 000 ₽ (это около 60 сделок в месяц), и предположить, что 10% сделок зависает именно из-за задержки в подготовке документов — не из-за клиента, а из-за отсутствия регламента приоритизации в документообороте, — набегает риск незакрытой или отложенной выручки ≈900 000 ₽ в месяц (оценка: 6 сделок × 150 000 ₽). Это сопоставимо с фондом оплаты труда всего отдела за месяц — при ставке ~120 000 ₽ на менеджера ФОТ отдела составляет ≈720 000 ₽. Регламент здесь не отменяет нехватку рук, но переводит вопрос из «все горят» в конкретное решение: выделенный сотрудник с оплатой за задачу-результат либо распределение между свободными людьми по чёткому правилу очерёдности. Важно не путать вклад разных инструментов в итоговый эффект. Автоматическая проверка регламентов через ИИ экономит время на контроле формальных пунктов — это отдельный, небольшой вклад, измеряемый часами проверяющего и токенами модели. Экономия на зависших сделках или на лишних каналах связи из примеров выше — это эффект самого регламента и аудита как управленческого решения, а не ИИ-инструмента, который лишь ускоряет проверку уже написанного правила. Складывать эти цифры в одну «экономию от автоматизации» некорректно — это разные по природе источники экономии. Правило, которое не пишут в должностной инструкции Оно вам понадобится, когда регламент столкнётся с реальностью: что делать сотруднику, если инструкция противоречит здравому смыслу. Есть ещё один тип регламента, который редко формулируют письменно, но который держит всю систему. Собственник одной компании сформулировал его так: «Вы должны развиваться с бизнесом. В тот момент, когда бизнес вас обогнал — всё. В тот момент, когда вы не соответствуете бизнесу — всё». Это не про должностные обязанности, а про условие, при котором вся остальная стандартизация имеет смысл: сотрудник, который перестал расти вместе с процессами, рано или поздно станет узким местом, сколько бы инструкций для его роли ни было написано. Практическое применение этого правила видно на примере с высокоэффективным менеджером, у которой не осталось свободного времени в течение дня и которая упёрлась в карьерный потолок. Вместо увольнения ей предложили возглавить проект автоматизации — регламент роста для сотрудника оказался частью регламента развития всей компании, а не отдельным ритуалом отдела кадров. Из всего этого складывается не универсальная методичка, а рабочий признак: регламент рождается из конкретного сбоя, а не пишется заранее «про запас». Он привязан ко времени или чёткой точке в процессе — а не к общей формулировке обязанности. Закрепляется после нескольких попыток, а не с первого раза на бумаге. И пересматривается, когда меняются роли, — как в случае с разделением обучения новичков и управления опытной командой. Сам по себе документ при этом верхний слой, а не замена процессу: как процесс описывают, меряют и доводят до владельца — отдельный разговор. Чек-лист: с чего начать в понедельник Выберите один повторяющийся сбой за последнюю неделю — перебивания, нестыковку цифр в двух отчётах, задачу без ответственного — и опишите его в одном предложении. Спросите у трёх человек, вовлечённых в процесс, как они выполняют это действие сейчас. Если ответы разные — регламента нет, есть только ощущение, что «все всё знают». Назначьте конкретное время или точку в процессе для этого действия — не «по мере необходимости», а «с 10 до 11» или «после подписания договора, до передачи в производство». Зафиксируйте первую попытку выполнения по новому правилу текстом или диктофоном. Не редактируйте задним числом — фиксируйте то, что реально произошло. Пройдите цикл из трёх итераций и закрепите правило инструкцией только после того, как третий раз получилось без ручного контроля. Если проверка регламента формальная — есть срок, есть ответственный, есть точка контроля, — соберите её в чек-лист и попробуйте автоматизировать проверку промптом, прежде чем поручать это человеку каждый раз заново. Регламенты, которые читают, — не те, что написаны красивее. Это те, что описывают уже произошедший сбой и закрывают ему дорогу назад. Остальное — красивый дом без дверей. Возьмите на этой неделе один свой регламент и проверьте его на исполнителе: дайте прочитать и попросите пересказать, что он будет делать. Если пересказ не совпал с вашим замыслом — виноват документ, а не человек. Как превратить регламенты в то, что машина сможет проверять автоматически, — в бесплатном курсе . Что я понял про регламенты за эти годы Мой главный вывод неприятный для любителей порядка: регламент нельзя написать один раз. Мы пробовали — получили красивую папку, которую никто не открывал. Работать начало, когда я принял, что каждый документ живёт, пока его проверяют, и умирает в тот день, когда проверка прекращается. Второй вывод: писать должен тот, кто делает. Мои регламенты, написанные из кабинета, разваливались о реальность на первой же неделе — я не знал деталей, которые для исполнителя очевидны. Сейчас я формулирую задачу и критерий приёмки, а текст пишет человек, который эту работу выполняет. И третий: если для соблюдения нужна ваша воля — регламента нет. Есть ваше личное присутствие, которое нельзя масштабировать. Если называть вещи своими именами, это отдельный управленческий навык: превратить разовый сбой в правило, которое держится без вас. Руководитель, который умеет это делать, стоит дороже руководителя, который каждый раз объясняет одно и то же заново, — и осваивать этот навык придётся, потому что на объяснениях вручную компания дальше десяти человек не растёт. Что сделать на этой неделе: возьмите один процесс, который у вас регулярно ломается, и опишите его в пять шагов — с человеком, который эту работу делает. Проверьте на нём же. Дальше решите, нужен ли вам следующий. Как поставить автоматическую проверку соблюдения — в бесплатном курсе для руководителей .

## База знаний компании: почему вики умирают и что работает вместо них
URL: https://davidgerstein.pro/blog/baza-znanij-kotoroj-polzuyutsya/
Дата: 2026-06-04
Направление: Операционное управление
Цифры: 80 / 22 / 17 — три ответа на один запрос · 40→7 минут на инструкцию · 3 попытки до рабочей инструкции
Коротко: Рабочая база знаний компании — это не вики-портал, а побочный продукт ежедневных действий: после трёх неудачных попыток решить задачу сотрудник надиктовывает шаги, и модель за 5–7 минут упаковывает их в инструкцию вместо 40 минут ручного написания. Портал на огромное число вопросов без понятной точки входа не работает — люди всё равно возвращаются с вопросами в чат, а не в поиск.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. У вас есть база знаний? А ей кто-нибудь пользуется? Если у вас, как у большинства, разговор глохнет на втором вопросе — диагноз простой: база есть почти у всех, пользуются единицы. Продолжение тоже знакомо: люди всё равно идут спрашивать в чат, потому что так быстрее. Я собрал за карьеру три таких кладбища. Ниже — что делает базу живой, и это не про инструмент: с любым инструментом можно сделать и работающую вещь, и мёртвый архив. Руководитель попросил выгрузить список клиентов одного региона из воронки. Получил три числа: 80, 22, 17. Три человека, три фильтра, три версии правды. Никто не соврал — каждый смотрел в свой кусок системы. Это и есть цена отсутствия единого источника данных: не хакерская атака и не саботаж, а обычный рабочий день, где база знаний компании существует в головах, а не в системе. На выяснение, какое из трёх чисел верное, ушла встреча с тремя участниками — по грубой прикидке это час-полтора рабочего времени трёх сотрудников, то есть 3–4 часа × 1000 ₽ ≈ 3–4 тыс. ₽ за один эпизод (оценка). А таких эпизодов в месяц — не один. Дальше — не про то, как красиво оформить вики. Про то, почему такие порталы умирают через полгода после запуска, и что вместо них реально работает в операционке: механика по шагам, конкретный промпт для превращения голосового сообщения в инструкцию и честная экономика — сколько это стоит и что снимает. Почему база знаний не работает и что с этим делать База умирает по одной причине: спросить коллегу быстрее, чем найти ответ. Пока это так, вы проигрываете чату — независимо от того, какой инструмент купили. Три правила живой базы: она пополняется автоматически из разборов и планёрок, а не подвигом энтузиаста; у каждой статьи есть срок годности, после которого она уходит на проверку; и поиск в ней работает быстрее, чем вопрос в чате. Проверка простая — дайте новому сотруднику найти ответ на реальный рабочий вопрос и засеките время. Три ответа на один вопрос — это диагноз Задайте своей команде один рабочий вопрос в общем чате и посмотрите, сколько разных ответов вы получите. Если больше одного — у вас нет базы знаний, у вас есть коллективная память, и она у каждого своя. История с 80/22/17 показательна тем, что проблема не в CRM и не в квалификации людей. Проблема в децентрализованном хранении данных: у каждого свой фильтр, своя выгрузка, своё понимание, что считать «активным клиентом». База знаний компании — это в первую очередь не документ с инструкциями, а согласованный источник правды: где лежит актуальная цифра, кто её обновляет, как её проверить. Если у отдела нет единого места, где хранится актуальное состояние процесса — количество клиентов, статус договора, версия регламента, — люди начинают спрашивать друг друга. Спрашивают и дело не в лени: спросить быстрее, чем искать в трёх системах одновременно. Красивый дом без дверей Так выглядит большинство баз, которые я видел, включая мои первые: содержание есть, входа нет. Проверьте свою — сможете ли вы за минуту найти в ней ответ на вопрос, который вам задали вчера? Одна команда собрала базу на огромное число вопросов. Разработчик подготовил контент и дизайн, передал технической команде — и там всё встало. Несколько операций подряд, неделя работы — а войти в систему нормально не получалось. По итогу — «красивый дом, но дверей нету, как зайти непонятно». Разрыв случился не из-за нехватки данных. Данных было в избытке. Разрыв — между контентом и разработкой: никто заранее не сформулировал техническое задание на то, как человек должен искать ответ, сколько кликов ему на это нужно, что происходит, если он не знает точного термина. Где ломается Большая база знаний без продуманного входа хуже маленькой без базы вообще. Люди не будут листать сотни тысяч записей в поисках одной. Они пойдут в чат и спросят коллегу — а коллега оторвётся от своей работы, и цикл повторится. Тот же принцип разделения контента и упаковки работает и в производстве документов: в одной компании производственный цикл разбит на два блока — «производство» (сбор материала, интервью, структура) и «упаковка» (редактура, вёрстка, финальный вид). За оба блока отвечает один проект-менеджер, но исполнители разные. С базой знаний то же самое: тот, кто пишет контент, и тот, кто делает его доступным, — разные компетенции. Если это не разделить осознанно, получится дом без дверей. Почему ваши сотрудники всё равно спрашивают в чате Ответ неприятный: потому что спросить быстрее, чем искать. Пока это так, ваша база проигрывает чату по единственному критерию, который важен исполнителю. Финансовый сотрудник жаловался, что коллеги постоянно перебивают его просьбами об оплатах и срочных операциях. Он не успевал с основной работой и начал сомневаться в собственной компетентности. Руководитель разобрался — и корень оказался не в характере коллег и не в квалификации финансиста. Корень — в отсутствии структуры: не было выделенного времени в расписании, когда платежи обрабатываются, и все знали бы, что до 10 и после 11 дёргать бесполезно. Это тот же класс проблемы, что и с базой знаний. Люди спрашивают не потому что не хотят искать сами, а потому что не знают, где и когда искать, и им проще получить ответ живьём. Руководитель маркетинга описывал это так: «Я бы хотел погруженно работать, ну, взял задачу, в неё погрузился и час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать, это прям невероятная удача». Постоянные прерывания — это не только про отсутствие документации. Это про отсутствие правил, к кому и когда обращаться. База знаний без регламента «в какое время это решается» ломается так же, как регламент без базы знаний, куда за ответом идти. Механика: как база собирается по шагам Мы шли этим путём дважды: первый раз с конца — выбрали красивый инструмент и начали в него переносить, и умерли на третьей неделе. Второй раз с начала — с правила, откуда берутся статьи. Второй заход дожил до сегодня. Порядок для вас: сначала правило пополнения, потом структура, и только потом инструмент. Обратный порядок — с выбора платформы — и есть главная причина мёртвых баз. Рабочая версия строится не сверху вниз (сначала портал, потом контент), а снизу вверх — из повторяющихся действий, которые уже происходят. В одной компании ввели простое правило: каждое выполняемое сотрудником действие либо документируется как инструкция, либо записывается на диктофон для последующей расшифровки. Схема такая: Три попытки. Сотрудник берётся за задачу: первый раз — не вышло, второй — снова мимо, но уже по-другому, третий — получилось. Вот на этом моменте включается фиксация. Чем фиксируется. Сотрудник не пишет текст — надиктовывает на диктофон или в голосовое сообщение, что он сделал, шаг за шагом. Куда попадает. Запись автоматически транскрибируется и упаковывается моделью в структурированную инструкцию (шаги, формат, условия применения). Кто и когда смотрит. Черновик инструкции уходит на проверку владельцу процесса (не автору, а ответственному за раздел базы), тот подтверждает или правит формулировки — без ручного набора текста с нуля. Что дальше. После публикации к вопросу больше не возвращаются — при повторном возникновении такой же ситуации сотрудник получает ссылку на инструкцию, а не устный ответ. Смысл в том, что база знаний не пишется отдельным проектом «в свободное время», которого ни у кого нет. Она собирается как побочный продукт обычной работы. Похожий принцип уже применяется для автопостинга: менеджеры записывают голосовое по итогам дня, данные транскрибируются и упаковываются в готовый текст — подробнее об этой механике в статье о том, как планёрка документирует себя сама . Это снимает главный вопрос, который убивает попытки завести базу знаний: «кто будет её вести». Никто отдельно — она собирается из того, что люди и так делают, если процесс правильно настроен. ИИ-связка: от голосового до инструкции Конвейер простой и его можно повторить на любом стеке, где есть Telegram-бот и вебхук: голосовое сообщение → транскрибация → структурирование моделью → черновик в таблице → проверка человеком → публикация. Шаг транскрибации — это распознавание речи (модель уровня Whisper или встроенный STT платформы), он не требует рассуждений, только точность звука в текст. Шаг упаковки в инструкцию — это уже работа с текстом: выделить шаги, убрать оговорки, не потерять смысл. Здесь достаточно дешёвой модели: команда уже проверяла на своём проекте — дорогая модель и модель подешевле дали идентичный результат на одном и том же промпте структурирования текста. Переплата за токены на такой задаче — чистые потери. Упаковка расшифровки в инструкцию — далеко не единственное, что машина делает с текстом: есть шесть ступеней — от писем и документов до таблиц и подключения к вашим системам . Промпт для шага «упаковка» (вебхук из Telegram-бота или Make/n8n-сценария, вход — JSON с транскриптом): Пример ответа модели: Инженерная обвязка: Telegram-бот принимает голосовое сообщение → вебхук в n8n (или Make) передаёт файл в API транскрибации → текст уходит в модель по промпту выше → результат складывается черновиком в Google Sheets (колонки: employee_id, title, steps, unclear, status) → ответственному за раздел базы приходит уведомление в Telegram с ссылкой на черновик. Если транскрибация вернула пустой текст или файл повреждён — бот отвечает сотруднику «не расслышал, запишите ещё раз», а ошибка логируется в отдельный технический чат, чтобы не потерять сигнал молча. Перезапуск ручной: по task_id можно повторно дёрнуть вебхук без пересборки всей цепочки. Так выглядит сам черновик в таблице, прежде чем владелец раздела его подтвердит: Черновики базы знаний — Google Sheets 10–20 новых инструкций в месяц employee_id title status manager_14 Оформление договора с ускоренным тарифом на проверке manager_09 Возврат по договору опубликовано Второй полезный промпт — не для создания инструкций, а для их прополки. База без аудита ведёт себя так же, как неконтролируемые подписки на сервисы: в одной компании обнаружили, что за месяц число оплаченных коммуникационных каналов выросло в несколько раз — просто потому что никто не проверял, действительно ли они используются. С базой знаний тот же риск: статьи копятся, дублируются, устаревают, и никто это не считает, пока объём не станет неуправляемым. Модель здесь та же дешёвая: задача — сравнение текстов и дат, не творческая генерация. Запускать такой аудит достаточно раз в месяц вручную по кнопке или по расписанию в том же n8n. Что видно на цифрах: где теряется время без базы знаний Ситуация Что происходит Оценка потерь Три версии выгрузки клиентов (80/22/17) Сотрудники сверяют вручную, кто прав ~3–4 часа на эпизод (оценка) Финансиста прерывают вопросами об оплатах Нет расписанного окна приёма запросов рабочий день дробится на отрезки по 15 минут Портал с огромным числом вопросов без точки входа Пользователи не находят нужное база не используется, возврат к вопросам в чате Ручное заполнение ежедневного отчёта Данные собираются вручную, а не тянутся из CRM ~30 минут в день, ~10 часов в месяц (оценка) На диаграмме ниже — те же потери в пересчёте на минуты в день по каждому сценарию: Прерывания вопросами коллег 45 мин/день Ручной ежедневный отчёт 30 мин/день Поиск нужной версии данных 20 мин/день Поиск в портале без входа не используется Вики, которая умирает База знаний, которой пользуются Отдельный проект «когда будет время» Побочный продукт ежедневных действий (диктофон, расшифровка) Контент собран без ТЗ на вход и поиск Точка входа продумана до того, как написана первая статья Автор статьи неизвестен, обновлять некому У каждого раздела есть владелец Правится раз в квартал по инициативе Правится по факту: 3 неудачные попытки — новая инструкция Экономика: что это стоит и что даёт Настройка вебхука, транскрибации и промпта — разово 8–15 часов инженера; эксплуатация — счёт за токены и STT на порядок ниже стоимости одного часа сотрудника в месяц (оценка); прямой эффект на одной инструкции — экономия около 30 минут (с ~40 до ~7 минут), а на отдел набегает порядка 20 часов в месяц за счёт снятых прерываний (оценка). Разберём вклад именно механики «диктофон → расшифровка → инструкция», не смешивая с другими инициативами вроде мониторинга звонков или дашбордов — у них своя отдельная экономика. Стоимость внедрения. Формула словами: (часы инженера на настройку) × (ставка часа инженера) = разовые вложения. Настройка вебхука Telegram-бота, сценария транскрибации и промпта упаковки в n8n или Make — разовая работа инженера, оценочно 8–15 часов на первую рабочую версию (тестирование, обработка ошибок, шаблон в Google Sheets). По стандартной для рынка часовой ставке инженера это укладывается в диапазон одного-двух рабочих дней специалиста (оценка). Стоимость эксплуатации. Формула словами: (число инструкций в месяц) × (стоимость транскрибации и вызова модели на одну инструкцию) = счёт за месяц. Транскрибация голосовых и работа дешёвой модели на структурирование текста — низкий по объёму трафик токенов. При потоке 10–20 инструкций в месяц счёт за месяц остаётся на порядок ниже стоимости одного часа работы сотрудника — на порядок дешевле часа одного сотрудника. Прямой эффект. Формула словами: (сэкономленные минуты на одну инструкцию) × (число новых инструкций в месяц) ÷ 60 × (ставка часа сотрудника) = прямая экономия в месяц. Возьмём небольшой отдел и консервативную оценку: письменная инструкция руками отнимала у автора порядка 30–40 минут — по аналогии с другими ручными задачами фиксации данных в отделах, например ежедневный отчёт вручную занимал около 30 минут в день, — а через диктофон и автоматическую упаковку — 5–7 минут надиктовки плюс проверка черновика владельцем раздела. Экономия на одну инструкцию — около 30 минут, консервативно. При 10 новых инструкциях в месяц: 30 мин × 10 ÷ 60 = 5 часов в месяц — меньше одного рабочего дня одного сотрудника. Немного — это только прямая экономия на написании текста. На диаграмме — сравнение времени на одну инструкцию до и после ИИ-упаковки: 40 мин было 7 мин стало Экономия времени на одну инструкцию — с ~40 минут ручного написания текста до ~7 минут надиктовки на диктофон и проверки черновика владельцем раздела (оценка). Косвенный эффект больше прямого. Он не в скорости написания, а в снятых прерываниях. Формула словами для своего случая: (число сотрудников) × (минуты в день на устные вопросы коллегам) × 20 рабочих дней ÷ 60 = потери на прерывания в часах в месяц; доля, которую снимает рабочая база знаний (сотрудник находит ответ сам, не отвлекая коллегу), — это и есть ожидаемый эффект. Если у небольшого отдела уходит хотя бы 15 минут в день на «спросить коллегу вместо поиска в базе» на человека — а по цитате из этой же компании 15 минут непрерывной работы уже воспринимаются как удача, — суммарно на отдел набегает пара часов в день, ×20 рабочих дней = порядка 40 часов в месяц — почти целая рабочая неделя одного сотрудника. Если рабочая база знаний закрывает хотя бы половину таких вопросов напрямую, консервативная оценка снятого риска — около 20 часов в месяц, то есть половина обычной рабочей недели. Это оценка вклада именно базы знаний: сдвиг в реальных компаниях обычно даёт связка из базы знаний и регламента приёма запросов, вклад одного инструмента отдельно выделить нельзя. Что мы не считаем эффектом: время, которое сотрудник тратил на устные ответы коллегам, никуда не делось из его дня как «сэкономленное» — оно просто перестало быть прерыванием и стало временем на его собственную задачу. Это реальный выигрыш в фокусе внимания, но не прямая строка в бюджете, и складывать её с прямой экономией на написании текста нельзя — это два разных по природе эффекта. Правило Не запускайте базу знаний как отдельный проект с отдельным дедлайном. Она либо встроена в то, как люди уже работают, либо превращается в дом без дверей, о котором вспоминают на архивной полке. С чего начать в понедельник Выпишите три-пять вопросов, которые вам или коллегам задают чаще всего устно за последнюю неделю, — это и есть первые статьи базы, а не абстрактный план разделов. Назначьте владельца на каждый будущий раздел базы поимённо, а не «на отдел» — раздел без владельца устаревает первым. Настройте один канал приёма голосовых сообщений (Telegram-бот) для фиксации того, «как я это сделал», даже если технической упаковки в инструкцию ещё нет — начните с ручной расшифровки. Проверьте точку входа: сможет ли новый сотрудник за минуту найти ответ без вопроса коллеге. Если нет — чините вход, а не добавляйте контент. Введите правило трёх итераций: неправильно — неправильно — правильно, и на третий раз действие обязательно закрепляется инструкцией, а не остаётся в памяти исполнителя. Через месяц прогоните реестр статей через промпт-аудит — устаревшие и дублирующие статьи убивают доверие к базе быстрее, чем их отсутствие. Три числа — 80, 22, 17 — из истории в начале статьи чинятся не новым порталом. Чинятся правилом: один источник, один владелец, один способ проверки. Похожая логика применима и к контролю качества работы людей — переопределённые оценки в этой компании сначала показывают пробел и рекомендацию, а не штраф, и это тоже форма базы знаний, только персональной. Подробнее — в материале про контроль качества звонков без ОКК . А там, где база знаний должна пополняться из сканов и фото документов, а не из голосовых, полезно посмотреть, как точность распознавания документов выросла с 59% до 85% . Всё остальное — красивая обёртка, которая рано или поздно останется домом без дверей. Проверьте свою базу одним способом: попросите нового сотрудника найти в ней ответ на реальный рабочий вопрос. Если он вернётся с пустыми руками или пойдёт спрашивать коллегу — база не работает, сколько бы статей в ней ни было. Как сделать так, чтобы знания попадали туда автоматически — из планёрок, переписок, разборов, — механика в бесплатном курсе для руководителей . Три правила, которые сделали нашу базу живой Первое: пополняется автоматически. Если наполнение базы — отдельная задача в чьём-то списке, она не будет выполняться. У нас статьи рождаются из разборов и планёрок, а не из подвига одного энтузиаста. Второе: у каждой статьи есть срок годности. Не обновлялась полгода — попадает в список на проверку. Устаревшая инструкция хуже отсутствующей: по ней сделают неправильно и с чистой совестью. Третье: искать проще, чем спрашивать. Пока поиск в вашей базе работает хуже, чем вопрос в чате, вы проигрываете. Это единственный критерий, который вам стоит замерять. И замерять его руками, а не верить отчёту о числе статей, — отдельный навык руководителя: вопрос звучит не «сколько у нас документов», а «за сколько секунд новый человек нашёл ответ». Начните с одного: возьмите вопрос, который вам задают чаще всего, и запишите ответ туда, где ваши люди его найдут. Один вопрос в неделю — и через год у вас будет база, которой пользуются. Как автоматизировать пополнение из планёрок и переписок — в бесплатном курсе . Мы у себя завели правило: любой вопрос, заданный дважды, становится статьёй. Не идеально, зато работает без отдельного человека — и через полгода у нас накопилось ядро, которым реально пользуются.