Pyrus: возможности и что автоматизирует ИИ-агент в согласовании заявок

Компания уже жила в Pyrus: заявки на оплату счетов, заявки снабжения на закупку, служебные записки, кадровые заявки, обращения подразделений в ИТ-службу и в хозяйственный отдел, согласование договоров и приложений — всё это шло формами и маршрутами внутри системы, а не в почте. Процессы были описаны, роли назначены, сроки проставлены. Но решения по-прежнему принимались по пересказу: руководитель видел не картину, а реплику «заявка на согласовании, вернусь с деталями». Между тем, что система знает о заявке, и тем, что видит человек, который принимает решение, остаётся ручная работа: собрать согласующих, сверить сумму с учётом, понять, что этот поставщик уже подвёл, и успеть до конца месяца. Этот разрыв закрывает ИИ-агент — программа, которая по заданному правилу сама читает данные систем и выполняет шаги.

Процессный контур в российских компаниях давно зрелый, а скорость решений — нет. По исследованию Фонда «Сколково» и аналитического центра TAdviser, совокупная выручка российских разработчиков систем управления бизнес-процессами по итогам 2025 года составила 33–34 млрд рублей, и главный сдвиг внутри рынка — ставка на искусственный интеллект: средний уровень развития ИИ-функций у платформ-лидеров 83% против 31% у остальных участников. Там же зафиксирована смена подхода: на место роботизированной автоматизации (RPA, Robotic Process Automation — программные роботы, повторяющие действия человека по правилам) всё чаще приходят ИИ-агенты, которые работают на стыках между системами. По опросу hh.ru (май 2025 года, 3283 респондента), 38% работников тратят на согласование документов, заявок и запросов больше шести часов в неделю, а у 46% сотрудников кадровых служб на это уходит свыше шести часов еженедельно. По бенчмаркам Ardent Partners, счёт в среднем идёт от получения до согласования 8,2 дня, а у компаний с лучшими показателями — 2,9 дня. Заявок и счетов меньше не становится, а время на решение остаётся тем же — здесь и теряются дни.

Сразу договоримся о границах, чтобы не было ожиданий «ИИ вместо процесса». Pyrus остаётся рабочим местом: формы, маршруты, сроки, реестры, обсуждения, вложения и история живут там же, где жили. ИИ-агент не заменяет систему и не переписывает регламенты — он читает то, что уже накоплено в ней и вокруг неё, сопоставляет с данными учётного контура и возвращает результат обратно: в задачу, в поле заявки, в сводку ответственному. Дальше разберём по порядку: что система закрывает сама, где проходят её границы и что добавляет агент поверх.

Коротко

Pyrus закрывает процессы внутри компании: формы заявок, маршруты согласования, сроки этапов, реестры, доступы и отчётность. Границы начинаются там, где заявку нужно сопоставить с учётными данными, сроками по договорам и перепиской. Этот слой снимает ИИ-агент: он следит за этапами, находит расхождения, разбирает текст и собирает сводку по решениям, а согласование, подпись и платёж остаются человеку.

Содержание

• Что умеет Pyrus и какие процессы в нём живут
• Где проходят границы возможностей платформы
• Почему заявка, зависшая на согласовании, видна поздно
• Что съедает время между заявкой и решением
• Что делает ИИ-агент поверх Pyrus
• Какие риски это снимает
• Сколько часов это возвращает
• Чеклист: 10 мест в согласовании заявок, где агент снимает ручную работу
• Что остаётся за человеком
• Как это выглядит на практике
• Как внедрить поэтапно
• Источники

Что умеет Pyrus и какие процессы в нём живут

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

Формы и заявки

Процесс в Pyrus начинается с формы. Поля добавляются и переставляются без программирования, поле можно сделать обязательным, неизменяемым с определённого этапа или зависимым от выбора в предыдущем поле: например, «вид затрат» появляется только для заявки на оплату, а «объект» — только для закупки под конкретную площадку. В форме есть подсказки и ссылки на инструкции, а данные из формы автоматически переносятся в печатную версию документа — счёт, договор, акт печатаются на корпоративном бланке. Компания с 100+ сотрудниками обычно запускает основные процессы за неделю, а в первый месяц настраивает десятки процессов: именно поэтому вход у платформы низкий, а ошибок в данных на старте мало.

Маршруты согласования и подпроцессы

Маршрут согласования — это последовательность или параллельная цепочка этапов с указанием роли и срока на каждом. Роли берутся из оргструктуры, а могут определяться значением справочника: сумма больше лимита — добавляется финансовый директор, поставщик из категории «оборудование» — подключается главный инженер. Подпроцессы дают ветвление любой сложности, данные между основной задачей и подпроцессом копируются в обе стороны, а результат подпроцесса может менять маршрут основной заявки. Это ровно та механика, из-за которой платформа закрывает процесс надёжнее почты: заявку нельзя закрыть, минуя шаг, если процесс так настроен.

Сроки, эскалация и реестры

У каждого этапа есть срок, а у процесса — реестр: табличный список всех заявок с фильтрами по срокам, ответственным и ключевым словам, с массовым редактированием и согласованием и выгрузкой в Excel. Соглашение об уровне сервиса (SLA, Service Level Agreement) настраивает срок обработки в зависимости от приоритета заявки, этапа, графика операторов и параметров обращения; на этапах, где исполнитель ни на что не влияет, срок можно заморозить. Практическая ценность здесь не в красивом дашборде, а в том, что по каждому процессу появляется измеримая история: сколько заявок в месяц, где стоит дольше всего, у кого перегрузка.

Оргструктура, доступы и контроль данных

Оргструктура — единый справочник иерархии, который влияет на доступы и используется в маршрутах; её импортируют из Excel или синхронизируют с Active Directory, чтобы сотрудники добавлялись и блокировались автоматически. По умолчанию человек видит только те задачи, где он участвует; доступы к реестру заявок, отчётности и настройкам настраиваются в каждом процессе, в том числе в зависимости от значений полей. Для агента поверх платформы это принципиально: он подключается не ко «всему Pyrus», а к тому перечню процессов и подразделений, который разрешён явно.

Коммуникации и база знаний

Каждая задача — это чат, где ничего не теряется и сообщения нельзя удалить; в чате назначают встречи и прикладывают файлы. Отдельно живёт база знаний: инструкции, регламенты, записи встреч, совместное редактирование, история версий, импорт статей из Confluence и Word, публичные папки для клиентов и партнёров. Для внутренней поддержки есть потоковая обработка: оператор ведёт несколько заявок из разных каналов в одном окне, а руководитель контакт-центра видит загрузку в режиме онлайн.

Аналитика и отчёты

Аналитическая сводка показывает ключевые показатели процесса (KPI, Key Performance Indicators — ключевые показатели эффективности): суммы сделок, объём задач, сроки обработки по каждому этапу, каналы обращений. Виджеты настраиваются, а новые добавляются SQL-запросами. Вывод для нашей темы простой: система честно отвечает на вопрос «сколько и как долго», но не отвечает на вопрос «что из этого требует решения сегодня и почему это стоит».

Встроенные ИИ-инструменты и интерфейс интеграций

В Pyrus есть два встроенных ИИ-инструмента. ИИ-ассистент вызывается прямо на странице задачи: находит ответ в задачах и базе знаний, собирает резюме статей и обсуждений, анализирует и сравнивает документы, проводит сверку по реестрам, превращает аудио- и изображения в текст, ищет ответственных по оргструктуре. ИИ-боты выполняют сценарий в процессе по текстовой инструкции: формируют ответы по материалам компании, классифицируют обращения, создают связанные задачи и заполняют поля, контролируют корректность данных, меняют статусы и могут выступать в роли согласующих. Работает это на архитектурном приёме RAG (Retrieval-Augmented Generation — генерация ответа с опорой на найденные в корпоративных данных фрагменты), настройка не требует программирования, а доступ ограничен ролевой моделью: ассистент видит только то, что доступно сотруднику, боты — только то, что разрешил администратор. Вендор относит ИИ-инструменты к тарифу «Облачный» для пользователей в России.

Второй платформенный слой — интеграции: маркетплейс расширений (мессенджеры, телефония, 1С и другие сервисы), API (Application Programming Interface — программный интерфейс для обмена данными) и скрипты. Без этой точки входа внешний агент поверх платформы не собрать. Платформа внесена в реестр российского ПО, соответствует 152-ФЗ (Федеральный закон «О персональных данных») и ставится как в облако, так и во внутренний контур компании; по данным вендора, она выдерживает работу компаний с более чем 100 тыс. сотрудников и объёмом до 1 млн задач в день, а самая масштабная установка на инфраструктуре клиента — системно значимый банк из топ-10: 50 000 сотрудников, 4 300 процессов, 200 млн документов, при этом 25 аналитиков настроили 90% процессов самостоятельно.

Как это же устроено в других контурах, мы разбирали отдельно: возможности Битрикс24 и роль ИИ-агента поверх портала, что добавляет агент системе управления задачами и разбор Directum RX как платформы документооборота. Логика везде одна: система остаётся, а между данными и решением появляется отдельный слой.

Где проходят границы возможностей платформы

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

• Система видит заявку, а не расход. Заявка согласована, но поставка по ней уже сдвинулась, цена в счёте отличается от прайса, а остаток на складе делает закупку ненужной. Сопоставить заявку с учётным контуром — отдельная работа.
• Встроенные ИИ-инструменты не выходят за периметр платформы. Бот действует внутри процесса по инструкции, ассистент помогает человеку на странице. Ни один из них не читает учётную систему, почту контрагента и не следит за сроком, который живёт в чужой системе.
• Маршрут работает по роли и лимиту, а не по обстановке. Он не знает, что этот поставщик дважды срывал срок, что цена выше рынка на 12% или что по такому же договору месяц назад вернули комплект документов.
• Отчёты считаются по зарегистрированным заявкам. Договорённость в мессенджере, письмо от поставщика, звонок снабженца в отчётность не попадают — а задержка чаще всего рождается именно там.
• Срок этапа не равен сроку решения. Заявка может формально идти по маршруту, пока согласующий ждёт уточнения по сумме. В системе это один статус «на согласовании», и он не отличает работу от простоя.
• Сводка руководителю собирается руками. Отчёты показывают цифры, но не отвечают на вопрос «что из этого требует моего решения сегодня». Этот слой обычно делает секретарь, экономист или сам руководитель.

Почему заявка, зависшая на согласовании, видна поздно

Причина не в дисциплине сотрудников. Причина структурная: между системой и решением нет слоя, который сопоставляет данные и доводит отклонение до человека, пока ситуацию ещё можно поправить.

Заявка создана, маршрут запущен — формально всё в порядке. Дальше начинается то, чего в системе не видно. Согласующий ушёл на площадку в Чайковский, а замещение не включено. Снабженец ждёт от поставщика уточнённую спецификацию, о которой написал в комментарии. Поставщик прислал счёт с новой ценой по электронной почте, а не через ЭДО, поэтому в карточке заявки этой цены нет. Бухгалтер обнаружила, что сумма расходится с заказом, и написала об этом в почте, а заявка всё это время стоит в статусе «на согласовании». Сводка к планёрке собирается вручную: часть данных из реестра, часть — из писем и из памяти.

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

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

Что съедает время между заявкой и решением

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

1. Заявку создают, вручную заполняют поля и прикладывают документы, если часть данных есть только в почте или в голове автора.
2. Определяют маршрут: кто согласует, в каком порядке, какие приложения нужны. Часто это переписка в мессенджере, а не правило в системе.
3. Снабженец или секретарь обходит согласующих: напоминает, уточняет, отвечает на вопрос «а зачем это вообще».
4. Финансовая служба сверяет сумму и номенклатуру с учётной системой, ищет связанный договор и историю расчётов с поставщиком.
5. Заявка возвращается автору на уточнение — и цикл повторяется с шага первого, но уже без прежней скорости.
6. Собирается сводка «что на согласовании, что просрочено, что ждёт решения» — обычно к планёрке и обычно вручную.
7. Решение принимается на совещании и снова попадает в систему текстом, без связи с тем, из-за чего заявка встала.

По опросу hh.ru, 38% работников тратят на согласование документов, заявок и запросов больше шести часов в неделю, а четверть — столько же на подготовку неавтоматизированных отчётов. По бенчмаркам Ardent Partners (опрос 204 специалистов по расчётам, публикация 2026 года), счёт в среднем идёт от получения до согласования 8,2 дня, у лучших команд — 2,9 дня против 13,5 у остальных, а доля счетов, которые уходят на ручной разбор из-за расхождений, составляет 18,4%. Только 35,4% счетов проходят весь путь без вмешательства человека. Эти часы никто не ворует: они растворяются в ручных сверках, повторных итерациях и в ожидании ответа.

Что делает ИИ-агент поверх Pyrus

Агент не переписывает маршруты и не ведёт свой реестр. Он подключается к платформе по её интерфейсу интеграций и работает с тем, что в ней есть, плюс с тем, что рядом: учётной системой, ЭДО, почтой, календарём.

1. Читает заявки и историю. Карточки и поля, вложения, комментарии, состав согласующих, сроки этапов, связанные договоры и заказы. Не весь архив платформы, а тот перечень процессов и подразделений, который указан в задании.
2. Сопоставляет заявку с учётным контуром. Сверяет сумму, номенклатуру, цену, условия оплаты и остатки с данными 1С:ERP: заявка на закупку против складского остатка, счёт против договора и заказа, платёж против графика. Как это устроено технически — в разборе про подключение ИИ-агента к учётным системам.
3. Следит за этапом и признаками простоя. Видит, что заявка стоит у согласующего дольше обычного, что замещение не включено, что до конца месяца осталось три дня, а на маршруте ещё пять платёжных заявок, — и пишет ответственному, пока ситуацию можно поправить.
4. Проверяет комплектность и типовые условия. Нет спецификации, не совпадает цена с прайсом, поставщик не в реестре одобренных, сумма выше лимита по этому виду затрат — заявка возвращается автору с перечнем замечаний до того, как попадёт к руководителю.
5. Разбирает текст и переписку. Достаёт из почты и комментариев то, что не попало в систему: обновлённую цену, обещанный срок поставки, замену позиции, протокол разногласий. Договорённость превращается в черновик задачи с ответственным и сроком — человек подтверждает одним действием.
6. Готовит проект решения и маршрут. По содержанию заявки предлагает, кто и в каком порядке согласует, какие приложения запросить, на какой счёт ссылаться. Решение о маршруте остаётся за человеком.
7. Собирает сводку по решениям, а не по цифрам. Не «на согласовании 47 заявок», а «сегодня решения требуют шесть: по двум просрочен срок у согласующего, по одной расхождение цены с прайсом, одна на повторном круге после уточнения, две ждут подписи, чтобы попасть в платёжный реестр до конца месяца».
8. Ведёт журнал сигналов. Что заметил, кому отдал, что решили, чем закончилось. Через две недели видно, какие сигналы подтверждаются, а какие агент ловит зря, — это и есть настройка, а не вера в инструмент.

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

Какие риски это снимает

Риски назовём первыми и конкретно: часы идут следом, потому что они — следствие. Считаем не «эффективность процессов», а сценарии: что происходит, кто платит и чем заканчивается.

Платёж ушёл по счёту, который не должен был пройти

Классический сценарий: счёт пришёл повторно с изменёнными реквизитами, сумма совпала, заявку согласовали по инерции. По данным APQC Open Standards Benchmarking, даже у лучших компаний 0,8% годовых выплат уходят как дублирующие или ошибочные платежи, у отстающих — 2%; на 200 млн рублей платежей это 1,6–4 млн рублей в год, и часть этой суммы возвращается только через переписку и зачёт. Агент ловит это до согласования: сверяет счёт с договором, заказом и историей платежей, и повторный счёт по той же поставке становится замечанием, а не проводкой.

Просрочка оплаты: пени по договору и проценты по статье 395 ГК РФ

Счёт, который девять дней шёл по маршруту, уходит поставщику позже срока. Дальше арифметика по договору: пени за просрочку платежа, потеря скидки за раннюю оплату (обычно 1–3% суммы), а при споре — проценты за пользование чужими денежными средствами по статье 395 Гражданского кодекса РФ. Отдельный эффект — отношения с поставщиком: у компании с просрочками сдвигается приоритет отгрузок, а в дефицитном сегменте это дороже любых процентов. Агент видит срок оплаты в момент создания заявки и не даёт ему пройти незамеченным.

Закупка прошла по инерции

Заявка на закупку без сверки с остатком и с рынком — это закупка по прошлогодней цене и в объёме, который уже лежит на складе. Проверить цену по двум-трём источникам, сопоставить заявку с остатком и с планом производства — работа на десять минут, которая не делается, потому что её никто не закрепил за собой. Итог: неликвид на складе и разница в цене, которая видна только при разборе закупки за квартал. Агент делает сверку по каждому лоту: остаток, средняя цена последних поставок, отклонение от прайса.

Подпись руководителя как бутылочное горлышко

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

Спор без доказательной базы

Договорённость о замене партии, об отсрочке или о снижении цены согласована в переписке, а регламент выполнен «по факту». Когда начинается спор, у компании нет ни даты, ни ответственного, ни версии: в системе — устаревшая заявка, в почте — переписка, которую никто не связывал с поставкой. Разбирательство выигрывает тот, у кого есть документы. Агент переносит договорённость из переписки в задачу с датой и автором — и она становится доказательством, а не воспоминанием.

Зависимость от одного человека

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

Сколько часов это возвращает

Часы — уже следствие: сначала снимаем риск, потом считаем освободившееся время. Ниже — типовой расчёт для контура, где обрабатывается 220 заявок в месяц (оплата, закупка, сервисные обращения) и участвуют 14 согласующих.

Показатель	Вручную	С агентом
Заполнение и проверка заявки, минут на заявку	9	2
Определение маршрута и состава приложений, минут на заявку	6	1
Сверка с учётной системой и историей поставщика, минут на заявку	7	1
Обход согласующих и напоминания о сроке, минут в неделю	300	40
Сборка сводки «на согласовании и на контроле», часов в неделю	4	0,5
Задержка с обнаружением застрявшей заявки, дней	5	1

Арифметика открытая, числа можно заменить своими:

• Оформление заявки. 220 заявок × 15 минут (заполнение, маршрут, сверка) = 3 300 минут, то есть около 55 часов в месяц. С агентом — 220 × 4 = 880 минут, около 15 часов. Освобождается примерно 40 часов в месяц.
• Контроль сроков. 300 минут в неделю — это 5 часов, или около 21 часа в месяц. С агентом остаётся 40 минут в неделю, около 3 часов. Экономия — около 18 часов в месяц.
• Сводка руководителю. 4 часа в неделю против 0,5 — 3,5 часа в неделю, около 15 часов в месяц.
• Деньги. По часовой ставке специалиста 700 ₽ и руководителя 1 500 ₽ это 40 × 700 = 28 000 ₽, 18 × 700 = 12 600 ₽ и 15 × 1 500 = 22 500 ₽ — около 63 100 ₽ в месяц, если считать все часы. Консервативно берём половину: примерно 31 500 ₽ в месяц, около 380 000 ₽ в год.
• На трёх площадках оборот заявок растёт примерно втрое при том же контуре агента: освобождается около 120 часов и порядка 95 000 ₽ в месяц в этом расчёте.

Два ограничения, которые честно называются сразу. Первое: часть освобождённого времени не сокращается, а перераспределяется — люди остаются в компании, но занимаются спорными заявками и переговорами с поставщиками, а не обзвоном согласующих. Второе: часы в таблице — оценка потенциала на типовом контуре, а не обещание результата; точная цифра зависит от того, сколько заявок реально ведётся в системе и сколько работы идёт мимо неё. И отдельно про скорость: встроенные ИИ-инструменты платформы развиваются релизами, а качество сигналов агента растёт по мере накопления журнала, поэтому эффект нарастает, а не появляется в первый день.

Чеклист: 10 мест в согласовании заявок, где агент снимает ручную работу

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

1. Заполнение заявки. Поля и приложения подтягиваются из договора, заказа и прайса, человек только проверяет.
2. Определение маршрута. Состав согласующих предлагается по сумме, виду затрат и категории поставщика, а не по памяти автора.
3. Заявка с неполным комплектом. Возвращается автору с перечнем недостающих документов до запуска маршрута.
4. Просрочка на подлёте. Сигнал приходит за дни до срока этапа, а не на планёрке в конце месяца.
5. Замещение и отпуск. Заявка не стоит неделю у человека, которого нет на месте.
6. Сверка с учётным контуром. Сумма, номенклатура и остатки не расходятся между заявкой, счётом, договором и заказом.
7. Сроки по договорам. Дата оплаты, условия отсрочки и скидка за раннюю оплату — под контролем, а не в календаре бухгалтера.
8. Разбор переписки. Обновлённая цена, новый срок поставки и замена позиции из почты попадают в задачу, а не теряются.
9. Типовые замечания. Поставщик не в реестре одобренных, превышен лимит, нет обязательного приложения — ловится до подписи.
10. Журнал сигналов и решений. Что заметили, кому отдали, что решили, чем закончилось — с датами и ссылками на заявки.

Что остаётся за человеком

• Решение по расходу. Агент показывает расхождение и предлагает вариант; платить или отказать, выбрать поставщика, согласиться на новую цену — решение человека.
• Согласование и подпись. Маршрут, подпись и платёж остаются за людьми: агент не согласует за участника и не отправляет деньги.
• Разговор с контрагентом. Предупредить о сдвиге срока, договориться о замене, уладить спор по качеству — человек. Агент готовит основание и факты.
• Изменение регламента. Менять маршрут, лимиты и правила процесса — задача владельца процесса, а не агента: он работает по тому, что настроено.
• Границы прав агента. Разрешено: читать данные перечисленных процессов, сопоставлять, считать, готовить проекты и сигналы. Запрещено: согласовывать, подписывать, менять маршрут, править карточки и отправлять что-либо контрагенту.

Как это выглядит на практике

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

Отдельно смотрели цепочку «счёт → оплата → отгрузка»: как заявка превращается в платёж, где её проверяют, на каком шаге появляется расхождение и кто о нём узнаёт первым. Договорённости с поставщиками и часть уточнений по ценам жили в переписке, а не в задачах, а сводка для руководителя собиралась к планёрке руками. Разрыв был именно между контурами: формально ни одна заявка не потеряна, фактически часть решений стояла и ждала человека. Измеренных «до и после» по этому проекту нет — замер не проводился, поэтому цифры в статье берутся из отраслевых исследований и открытого типового расчёта, а не из этой команды. Платформу менять не пришлось: работали с тем, что уже стояло.

Как внедрить поэтапно

1. Выбрать один процесс. Не «внедрить ИИ в согласование», а конкретную боль: заявки на оплату, закупки или внутренние сервисные обращения. Один процесс — один замер.
2. Снять исходную картину. Сколько заявок в месяц, сколько времени уходит на оформление и сверку, сколько просрочек ловится поздно, сколько заявок возвращается на повторный круг. Без этой цифры потом нечего сравнивать.
3. Определить данные и права. Какие процессы и подразделения агент читает, к каким системам подключается, что ему запрещено. Права — минимальные, доступ — только из внутренней сети.
4. Собрать сигналы в журнал. Первые две недели агент не действует, а только показывает: сигнал, основание, предлагаемое действие. Люди проверяют точность и отмечают ложные срабатывания.
5. Встроить в рабочий ритуал. Сводка приходит к планёрке, расхождения разбираются ежедневно, черновики задач подтверждаются в момент появления. Ритуал важнее технологии.
6. Расширять по подтверждённым точкам. Оставляем то, что подтвердилось, убираем шум, подключаем следующий процесс — обычно сверку цен с прайсом или контроль сроков оплаты по договорам.

Что в итоге

Pyrus — зрелая low-code платформа для процессов: формы и маршруты собираются без программирования, сроки и уровни сервиса настраиваются, реестры и отчётность дают измеримую историю, встроенные ИИ-инструменты снимают поиск ответов, разбор документов и рутинные сценарии внутри процесса. Но всё, что находится на стыках — между заявкой и учётными данными, между маршрутом и реальной обстановкой, между задачей и перепиской, — платформа не закрывает и не должна: это не её зона. Именно там и рождаются задержки, которые видны поздно.

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

Если хотите понять, что из этого списка даст эффект именно у вас, начните с одного процесса: посчитаем связку «агент + ваши системы» и скажем, где часы, а где риски. Остальные материалы по направлению собраны в разделе Внедрение ИИ.

Источники

• Что закрывает сама платформа: описание возможностей Pyrus — формы и обязательные поля, маршруты последовательного и параллельного согласования со сроками и ролями, подпроцессы, справочники, оргструктура с синхронизацией из Active Directory, управление доступами, соглашение об уровне сервиса, реестр заявок с фильтрами и выгрузкой, аналитическая сводка, шаблоны документов и база знаний: pyrus.com, возможности платформы. Данные вендора.
• Что умеют встроенные ИИ-инструменты: ИИ-ассистент (поиск ответов в задачах и базе знаний, резюме обсуждений, анализ и сравнение документов, сверка по реестрам, расшифровка аудио и изображений) и ИИ-боты (сценарии по текстовой инструкции, классификация обращений, заполнение полей, контроль данных, смена статусов, роль согласующего), архитектурный приём RAG, работа в рамках ролевой модели доступа: pyrus.com, ИИ-инструменты. Данные вендора, независимо не проверялись.
• Масштаб установки на инфраструктуре клиента (системно значимый банк из топ-10: 50 000 сотрудников, 4 300 бизнес-процессов, 200 млн документов, 25 аналитиков настроили 90% процессов), оценка нагрузки (более 100 тыс. сотрудников, до 1 млн задач в день), реестр российского ПО и соответствие 152-ФЗ: pyrus.com, главная страница продукта. Данные вендора.
• Рынок систем управления бизнес-процессами в России: исследование Фонда «Сколково» и TAdviser (июнь 2026) — совокупная выручка российских разработчиков по итогам 2025 года 33–34 млрд рублей, в оценке участвовали 22 разработчика при примерно 30 решениях на рынке; средний уровень развития ИИ-функций у платформ-лидеров 83% против 31% у остальных участников, ИИ-агенты рассматриваются как замена роботизированной автоматизации: sk.ru, публикация исследования.
• Сколько времени уходит на согласование в России: опрос hh.ru (проведён 5–12 мая 2025 года среди 3283 соискателей) — 38% работников тратят на согласование документов, заявок и запросов больше шести часов в неделю, 25% — столько же на подготовку неавтоматизированных отчётов, у 46% сотрудников кадровых служб на согласования уходит свыше шести часов еженедельно: CNews, публикация данных hh.ru.
• Сроки и стоимость обработки счёта: отчёт Ardent Partners «State of ePayables 2025» (выборка 204 специалиста по расчётам) — в среднем 8,2 дня от получения счёта до согласования, у лучших команд 2,9 дня против 13,5 у остальных, доля расхождений и исключений 18,4%, без вмешательства человека проходит 35,4% счетов; сводка бенчмарков приводится с указанием первоисточника: свод публичных бенчмарков с ссылками на исследование. Исследование вендорское, выборка 204 человека.
• Дублирующие и ошибочные платежи: APQC Open Standards Benchmarking (приводится в той же сводке бенчмарков) — 0,8% годовых выплат у компаний с лучшими показателями и до 2% у отстающих: свод публичных бенчмарков, раздел о дублирующих платежах.
• Ответственность за просрочку платежа: статья 395 Гражданского кодекса РФ «Ответственность за неисполнение денежного обязательства» — проценты за пользование чужими денежными средствами: КонсультантПлюс, текст статьи.