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

Модели живут в облаке, и это даёт свободу выбора. Инструменты, которыми агент пользуется, тоже ходят в интернет: поиск по документации обращается к облачным моделям векторизации текста, проверка контрагентов — к внешним сервисам вроде Контур.Фокуса и так далее. Агент обновляется из GitLab, CI/CD развозит изменения по стендам автоматически, мониторинг стекается в один дашборд. Нас это устраивало.

Недавно заказчик из промышленного сектора обратился к нам с задачей: «У нас закрытый контур, интернета нет и доступа к облачным API — тоже. Единственное, что у нас есть — это сервер с локальной моделью и наша внутренняя инфраструктура. Хотим такого же ассистента, как у вас». В статье рассказываем, как мы с этим справились. Спойлер: не без приключений.

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

Когда мы начали встраивать AI-агента в BPM-платформу, перед нами встала знакомая enterprise-задача: десятки клиентов, у каждого своя онтология, словарь, роли и ограничения безопасности. В одной компании «заявка на покупку» — это «реестр заявок», в другой — «карточкой закупки». Один клиент работает на изолированном контуре с локальной моделью, другой не даёт ассистенту доступ к почте и репозиториям. 

Традиционный ответ — форк репозитория под каждого клиента — при масштабировании превращается в ад поддержки: багфиксы не попадают автоматически, стоимость растёт экспоненциально, качество падает. Мы решили эту проблему иначе: per-tenant overlay позволяет кастомизировать поведение агента без изменения кода.

Вы знаете, сколько стоит сервер. У вас есть договор с хостинг-провайдером, инвойс от вендора, строка в ИТ-бюджете. А вот сколько стоят процесс согласования договора с клиентом, сопровождение в месяц, один цикл согласования заявки на закупку и другие процессы — сходу ответить сложно.

Большинство компаний на эти вопросы отвечают приблизительно. В лучшем случае — оценкой в Excel, где кто-то умножил количество сотрудников на среднюю зарплату и поделил на число проектов. В худшем — интуитивным ощущением руководителя, которое потом попадает в презентацию для инвесторов как «мы оптимизировали операционные расходы на 15%».

Проблема не в том, что никто не пытался посчитать, а в том, что получившаяся цифра не имеет отношения к реальности. McKinsey в исследовании Global Survey on AI фиксирует типичную ситуацию: около 60% организаций не видят EBIT-импакта от AI-проектов не потому, что технология не работает, а потому что никто не договорился, как именно измерять результат. Нет так называемого evidence pack — пакета подтверждённых данных, на который можно опереться при принятии решений. Без него пилот выглядит успешным на демо, но при масштабировании выясняется, что атрибуция была некорректной, а стоимость посчитана по-разному на разных этапах.

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

За каждым мероприятием стоит не только креативная идея, но и длительная подготовка: брифы, сметы, подрядчики, подписание документов и контроль оплат. В федеральном event-агентстве работу вели в разных программах, поэтому часть времени уходила не на подготовку проектов, а на ручные операции и сверку данных. Рассказываем, как собрали единый цифровой контур для всех подразделений агентства.

Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.

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

Чтобы подготовить КП по сложному инженерному проекту, одного менеджера недостаточно. Нужно собрать расчёты от нескольких специалистов, а после согласования решения проверить наличие сотен позиций на складе и докупить недостающее. Когда это ведут в разных системах, растёт доля ручных операций и риск ошибок. Рассказываем, как собрали единый цифровой контур для управления сложными продажами и закупками в on-prem BPMS на Linux и PostgreSQL.

В последние два года разговор об AI-агентах почти везде начинается одинаково. Берётся большая языковая модель, к ней подключаются инструменты — поиск, CRM, почта, база знаний, API — и дальше предполагается, что модель сможет сама выбрать нужный инструмент, вызвать его и на этом решить задачу.

На демо это часто выглядит убедительно. Пользователь задаёт вопрос, модель делает один-два вызова, получает данные и формирует ответ. Кажется, что этого уже достаточно, чтобы говорить об agentic-сценариях. Но как только AI попадает не в лабораторную среду, а в реальный корпоративный контур, довольно быстро выясняется, что одного вызова инструмента по MCP недостаточно.

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

Иными словами, между «модель умеет вызвать инструмент» и «получился надёжный корпоративный агент» лежит отдельный инженерный слой. 

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему tool calling сам по себе не делает ИИ корпоративным агентом, как эту проблему решает наш подход Agent Loop и как этот цикл устроен в реальной enterprise-среде.

Автоматизация бизнес-процессов заметно изменилась за последние годы. Если раньше во многих сценариях хватало маршрутизации, правил и несложной бизнес-логики, то сейчас в процессы всё чаще встраиваются более тяжёлые вычислительные задачи, например, интеграции с внешними AI-сервисами. Иными словами, автоматизация перестаёт быть только реакцией на событие и всё чаще становится вычислительным слоем внутри самого процесса. Но для того, чтобы система выдерживала нагрузку, нужен мощный язык исполнения.

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

Когда в компании говорят о модели подразделения, обычно имеют в виду что-то вполне привычное: положение об отделе, регламент, SLA, список ролей и зон ответственности. Формально этого достаточно: подразделение описано, обязанности зафиксированы, сроки обозначены.

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

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

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

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

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

Но как только возникает практический вопрос — что именно это подразделение обязано делать, по каким правилам, с каким SLA, где проходят границы его ответственности и как проверить исполнение, — оказывается, что в явном виде ответа нет.

Знания хранится в регламентах, в BPM-системе, в локальных договорённостях, в головах сотрудников. Пока команда стабильна, это ещё может работать. Но при росте нагрузки, смене руководителя, цифровизации или попытке встроить в контур AI всё начинает рассыпаться. Новый руководитель читает документы, которые не совпадают с реальностью. Аналитик восстанавливает процесс по кускам. Автоматизация покрывает отдельные сценарии, но не даёт целостной модели того, что именно подразделение обязано гарантировать организации.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему привычное описание подразделений перестало работать как управленческий инструмент, как мы подошли к этому через концепцию Организация как Код (OaC) и почему начали описывать подразделения не как функции на оргсхеме, а как исполняемые сервисные контракты. 

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

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

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

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье я расскажу, как работать с картой дальше, чтобы она не превращалась в красивый, но мёртвый артефакт. 

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

По данным Gartner, не менее 30% проектов в области генеративного ИИ будут заброшены сразу после проверки концепта к концу 2025 года. IBM фиксирует, что только 25% ИИ-инициатив дали ожидаемый возврат инвестиций. McKinsey сообщает: лишь треть компаний масштабируют ИИ-программы на уровне всей организации, и большинство из тех, кто видит эффект, оценивают его как «менее 5% операционной прибыли (EBIT)». Это не приговор технологии — это диагноз подходу: ИИ внедряют ради самого ИИ, не ответив заранее на вопрос, какой конкретный эффект он должен принести.

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

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, как мы пришли к построению Картографа, как он устроен и что показала первая неделя его работы.

Для компаний с разветвленной филиальной сетью оцифровка внутреннего документооборота уже давно стала необходимостью. ЭДО создает единое информационное пространство, позволяя моментально находить, подписывать и отслеживать приказы и заявки, а также значительно сокращает операционные затраты. Сегодня поделимся опытом федерального ритейлера, где потребовалось автоматизировать массовую выдачу УНЭП. Решение будет также полезно для крупных производственных и строительных предприятий.

У байеров крупных компаний самая горячая пора длится с сентября по декабрь. Чем больше поставщиков и номенклатуры, тем будет сложнее обойтись без специализированного софта, SRM-системы (Supplier Relationship Management). Рассказываем, как автоматизировали переговорные кампании на базе BPMS для закупок федерального DIY-ритейлера. Это решение также будет полезно производственным и сервисным компаниям, девелоперам и всем тем, кто хочет оцифровать процесс закупок для внутренних нужд.

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

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

Банк Синара разрушил все эти стереотипы и создал единый цифровой контур на базе BPMS. Сотрудники самостоятельно разработали методологию, внедрили систему, осуществили миграцию данных, настроили бизнес-процессы, интегрировались в ИТ-архитектуру банка. Теперь сами занимаются администрированием и развитием. Об этом и расскажем ниже.

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

Продолжаем делиться опытом консолидации IT-инфраструктуры Академии Ростеха и переходом на единую систему, объединяющую CRM, бюджетирование проектов, управление закупками и другие процессы. В этой статье поговорим о цифровизации HR-процессов и управления финансами.

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

В этой статье поделимся опытом консолидации IT-инфраструктуры Академии Ростеха и переходом на единую систему, объединяющую CRM, бюджетирование проектов, управление закупками и другие процессы.