Автоматизация бизнес-процессов
Цель: перевести рутинные бизнес-процессы в системы, которыми сотрудники пользуются каждый день. Каждая закрывает процесс целиком — от момента, когда возникает задача, до отчёта по ней.
Примеры реализованных решений
Корпоративный портал. Организационная структура как живой документ: штатное расписание по подразделениям, оргчарты, нормы управляемости. По каждой должности — комплект ролевых документов: карточка должности, матрица полномочий, порядок отчётности, порядок эскалации. Качество этих документов оценивает ИИ: показывает, где описание неполно или противоречиво, и подсказывает, что доработать. Рядом единое хранилище корпоративной документации с поиском, модуль управления задачами с делегированием и протоколы встреч.
Контроль качества. Движение заявок в отдел контроля качества: заявка идёт по маршруту согласования через смежные департаменты и попадает в отчётность.
Управление внутренним двором складского комплекса. Регистрация въезда и выезда транспорта на КПП, оформление пропусков, согласование выпуска транспортных средств и грузов со стороны таможни.
Управление грузовыми партиями 3PL (B2C логистика). Движение партий от приёмки до выдачи: статусы приходят из смежных систем сами, аналитика транзитного времени и объёмов, прибыльность направления.
Система организации биллинга. Выставление счетов по этапам: справочник контрагентов, тарификация, контроль SLA, карточки к выставлению создаются по расписанию автоматически.
Общее у всех — процесс перестаёт жить в переписке и таблицах. Данные вводятся один раз, ход дела виден всем участникам сразу, а отчёт собирается сам. Становится видно то, чего раньше видно не было: кто задерживает согласование, где стоит партия, сколько заработало направление.
Самостоятельные команды автоматизации в бизнес-подразделениях
Цель: научить бизнес-подразделение автоматизировать свои процессы самостоятельно — без ИТ-отдела, без подрядчиков и без передачи задачи на сторону. Код пишут сотрудники, которые знают процесс изнутри, с помощью ИИ.
Работа идёт тем же порядком, что и в профессиональной разработке: задача заводится и описывается, работа ведётся в отдельной ветке, изменения приходят пул-реквестом. Ревью прогоняет ИИ-агент по стандартам проекта и возвращает вердикт, а решение о слиянии принимает человек — руководитель подразделения как владелец процесса.
Как это реализовывается
- порядок работы, одинаковый для всех и записанный так, что его читают и люди, и ИИ-агенты
- инфраструктура: репозитории, защита главной ветки, разграничение доступов, отдельные среды для проверки и для боевой работы
- правила каждого проекта в самом проекте — единый контракт, по которому работают и сотрудник, и его агент
- автоматическое ревью: каждое изменение проверяется агентом по стандартам проекта до того, как попадёт к человеку
- обучение сотрудников — не программированию, а порядку работы
- владелец процесса — руководитель подразделения: он ставит задачи и принимает решение о выпуске.
Модель не привязана ни к отрасли, ни к конкретным людям: она держится на порядке работы, а не на том, что кто-то в подразделении умеет программировать.
Виртуальные сотрудники и ассистенты
Цель: передать виртуальным сотрудникам работу, которая сегодня отнимает людей целиком. Виртуальный сотрудник — это не программа, которую открывают, когда она понадобилась, а роль с постоянным участком работы: со своим расписанием, памятью о своём деле и правом обратиться к человеку, когда нужно решение.
Что можно передать
- приём входящего потока — письма, заявки, обращения — и превращение его в задачи
- наблюдение за системой: заметить сбой и предупредить раньше, чем его заметит человек
- регулярная отчётность и сводки, которые собираются сами, а не готовятся к совещанию
- проверка работы по заданным правилам — от ревью кода до полноты и непротиворечивости документов
- участие в рабочем обсуждении наравне с коллегами и там же, где оно идёт: в мессенджере, в почте, в самой задаче.
Отдельная роль — личный ассистент: задачи ставятся голосом, почта приходит выжимкой вместо списка писем, напоминания и встречи заводятся сами, утром готова сводка, нужное находится в личном архиве, а документ объясняется простым языком.
У каждого участка свой сотрудник — со своими правилами и своей памятью, а не один универсальный помощник на всё. Поэтому он отвечает по делу, не путает контексты и не повторяет ошибку, которую уже разобрали.
Агенты работают на собственном сервере: распознавание речи и обработка личных данных происходят там же, наружу уходит только то, для чего действительно нужна большая модель. Подробнее об устройстве — в последнем блоке.
Работа, которая раньше требовала внимания человека каждый день, идёт без него. Человек подключается там, где нужно решение.
Пользовательские продукты
Цель: пройти весь путь от замысла до опубликованного приложения. Автоматизация процесса заканчивается внутри компании. Продукт живёт иначе: его находят сами, он должен объяснять себя сам и работать без сопровождения. Это другой набор задач — замысел, дизайн, разработка, публикация в магазине приложений, оплата, поддержка живых пользователей.
Пример реализованного решения
Планометр — приложение, которое измеряет качество планирования. Работает на iPhone, iPad, Mac и в браузере.
Обычные планировщики хранят задачи. Планометр разбирает, как человек планирует: как часто переносятся дела, сколько за день появляется незапланированного, насколько плотно расписаны день, неделя и месяц. Из этого складывается индекс дисциплины — одна цифра, по которой видно, становится ли планирование лучше. Поверх этого работают ассистенты: с ними можно общаться текстом и голосом в реальном времени — поставить задачу, разобрать прошедшую неделю, спланировать следующую.
Приложение подключается к календарям и спискам задач и говорит на русском и английском. Само приложение бесплатное; функции с искусственным интеллектом, включая ассистентов, работают на кредитах — пользователь покупает их, только если они ему нужны.
Замысел, дизайн, разработка, публикация и поддержка — полностью в одних руках, с помощью искусственного интеллекта.
Интеграции систем
Цель: убрать границу, на которой данные переходят в руки человека. Отдельная система решает свою задачу и упирается в такую границу: дальше данные переносит человек — руками, письмом или таблицей.
Что для этого делается
- обмен между внутренними системами: данные, введённые один раз, появляются везде, где они нужны
- связь с внешними системами партнёров и подрядчиков через их интерфейсы: статусы, документы и справочники приходят сами
- единый вход и общие справочники: один человек — одна учётная запись, один список контрагентов на все приложения
- почта как рабочий канал: письмо превращается в задачу, ответ уходит в ту же цепочку, переписка остаётся историей
- мессенджер как рабочее место: уведомление, команда, отчёт и обсуждение там, где человек и так проводит день.
Что важно учесть: смежная система может замолчать, ответить ошибкой или прислать не то. Поэтому в связке заранее закладываются повторные попытки, защита от задвоения и понятный сигнал человеку — что именно не прошло и что с этим делать. Без этого интеграция держится, пока всё работает, и рвётся при первом сбое — молча, и заметят это не сразу.
Когда системы связаны, исчезает целый класс работы: сверки, перепечатывание из окна в окно и письма «уточните, пожалуйста, статус».
Мониторинг внешней информации
Цель: отсеять из внешнего потока то немногое, на что нужно реагировать. Событий каждый день больше, чем можно успеть прочитать. Решение принимают по нескольким из них, а время уходит на просмотр двухсот заголовков, половина которых об одном и том же.
Что делается
- сбор из источников разного типа — ленты, интерфейсы сервисов, сайты, научные публикации — по расписанию и без участия человека
- склейка повторов: одну историю пишут несколько изданий разными словами, и она распознаётся как одна, а не как пять
- перевод, если источник на другом языке
- краткое изложение — суть в несколько строк вместо статьи целиком
- оценка значимости: поток выстраивается по важности, а не по времени публикации
- дайджест в удобном канале: почтой, в мессенджере или на своей странице.
Что важно учесть: ценность даёт не сбор, а отсев. Источник может замолчать, сменить формат или начать перепечатывать чужое. Без склейки повторов и оценки значимости лента за пару недель превращается в тот же шум, от которого её заводили, — только теперь в собственном интерфейсе, и читать её перестают.
Тема задаётся при настройке: рынок и конкуренты, изменения в регулировании, упоминания компании, отраслевые публикации, технологии — или что угодно своё, вне работы. Механика одна и та же — меняется только то, за чем следить.
Несколько строк вместо двухсот заголовков — и о важном узнают тогда, когда на это ещё можно повлиять.
Флот агентов: как это устроено
Цель: держать десятки агентов в рабочем состоянии силами одного человека — чтобы одна и та же задача решалась одинаково, а не как повезёт. Один помощник в чате — ещё не система. Как только агентов становится несколько и работают они постоянно, вопрос смещается: не «что умеет модель», а как всё это управляется, ограничивается и не ломается без присмотра.
Из чего это складывается
- у каждого агента своё место работы — на своей машине, на сервере или в облаке; выбор по задаче, а не по моде
- свои права: агент может ровно то, что ему разрешено, и не больше
- свои навыки — многоразовые процедуры, которые выполняются одинаково каждый раз, а не придумываются заново
- запуск по расписанию и по событию, а не только по просьбе человека
- передача работы между агентами: тяжёлую часть можно отдать отдельному исполнителю и получить обратно результат, а не гору промежуточного
- автоматические проверки на каждое действие — срабатывают до того, как действие произойдёт
- сторожа, которые следят за самими агентами и сообщают, если кто-то встал или начал потреблять слишком много
- управление оттуда, где человек и так находится: терминал, мессенджер, почта.
Инструменты при этом разные: агентские среды — Claude Code, Codex, Hermes, — модели разных поставщиков, облачные и свои. Привязки к одному поставщику нет: устройство флота от него не зависит, а инструмент выбирается под задачу и заменяется, когда появляется лучше.
Что важно учесть: главная опасность не в том, что агент чего-то не сможет. Она в том, что он сделает что-то уверенно и неправильно — и доложит об успехе. Поэтому нужны ограничение прав, проверки, срабатывающие перед действием, и привычка агента показывать, на чём основан ответ. Без этого флот работает ровно до первой дорогой ошибки.
Собранная так система работает без ежедневного присмотра и сама сообщает, когда нужно вмешаться.
Память и знания проектов
Цель: дать людям и агентам одну память, которой можно доверять, — и держать её там, где идёт работа, а не в головах и не в папке, куда никто не заходит. В подразделении знание живёт в головах. Почему решили именно так, с кем договорились об исключении, что уже пробовали и почему отказались — это помнят люди, а не документы. Человек уходит в отпуск или меняет работу, и вместе с ним уходит часть того, на чём всё держалось. То же и с личным: удержать в голове всё, чем занимаешься, невозможно — и не нужно, если помнит система.
Что делается
- постоянная память проекта и подразделения: решения, причины, ограничения и ошибки, на которых уже обожглись, записываются там же, где идёт работа, а не в отдельной папке, куда никто не заходит
- поиск по смыслу, а не по точному слову: текст переводится в векторы — эмбеддинги, — и близкое ищется по смыслу, а не по совпадению букв. Нужное находится, даже когда спросили другими словами
- ответ по контексту, а не список ссылок: система сама находит нужные куски и отвечает на вопрос обычными словами, показывая, откуда взяла — чтобы можно было проверить
- индекс лежит рядом с данными, в компактной локальной базе (SQLite), а векторы считаются на своей машине: содержимое документов не уходит наружу ради того, чтобы по ним искать
- одна память для людей и для агентов: агент опирается на тот же источник, что и сотрудник, а не на свою отдельную базу
- новый участник получает контекст сразу — и человек, и агент, вместо трёх месяцев вхождения в курс дела.
Этот механизм принято называть RAG: модель отвечает не из того, что она когда-то выучила, а из твоих данных, найденных под конкретный вопрос.
Память разделяется по уровням. У каждого проекта своя — решения и ограничения по нему одному. У подразделения общая — регламенты, договорённости и накопленный опыт, одинаковые для всех его задач. У человека личная — то, что нужно только ему. Уровни не смешиваются: агент проекта не тащит на себе лишнее, а общее доступно всем, кому положено.
Что важно учесть: память врёт молча. Устаревший факт выглядит точно так же, как свежий, и обнаруживается это в момент, когда по нему уже приняли решение. Поэтому у записи о состоянии есть срок перепроверки, непроверенное помечается как непроверенное, а сама память регулярно пересматривается. Без этого она превращается в свалку, которой перестают доверять, — и становится бесполезной, даже оставаясь полной.
Знание перестаёт быть личным: оно не уходит вместе с человеком и не теряется между задачами.
Своя инфраструктура на собственном железе
Цель: ответить на вопрос, который задают последним, а решать нужно первым: где всё это работает и куда уходят данные.
Основа — собственный сервер, обычный настольный компьютер, а не стойка в дата-центре. На нём живут агенты, расписания, базы, поисковые индексы и сторожа. Там же выполняется то, что не должно покидать контур: распознавание речи, построение векторов для поиска, обработка рабочих и личных документов.
В облако уходит только то, ради чего оно и нужно, — большие языковые модели. Это осознанное разделение, а не вынужденный компромисс: держать модель такого размера у себя дорого и незачем, а вот отдавать наружу содержимое документов ради того, чтобы по ним искать, не нужно вовсе.
Что это даёт
- данные остаются у владельца: чувствительное обрабатывается на своём железе
- расходы предсказуемы: сервер куплен один раз, помесячно платят только за модели
- ничего не теряется при смене поставщика: модель можно заменить, а память, индексы, расписания и накопленные знания останутся на месте
- независимость от чужих решений: сервис закрылся, поднял цену или сменил условия — это не останавливает работу.
Что важно учесть: своё железо — это и своя ответственность. Нужны автозапуск после перезагрузки, резервное копирование и сторожа, которые заметят, что что-то встало, и скажут об этом. Без них «свой сервер» превращается в компьютер под столом, про который вспоминают, когда он уже неделю как не работает.
Поэтому всё описанное выше — не набор подписок на чужие сервисы, а система, которой владеешь.