Чтобы подготовить КП по сложному инженерному проекту, одного менеджера недостаточно. Нужно собрать расчёты от нескольких специалистов, а после согласования решения проверить наличие сотен позиций на складе и докупить недостающее. Когда это ведут в разных системах, растёт доля ручных операций и риск ошибок. Рассказываем, как собрали единый цифровой контур для управления сложными продажами и закупками в 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, бюджетирование проектов, управление закупками и другие процессы.

Российский рынок медтехники растёт. В начале 2024 года продажи крупных компаний поднялись на 38%. На это повлияло развитие новых технологий и тот факт, что государство поощряет локальное производство. Но продажа — это только начало. Сложное оборудование нужно настраивать и обслуживать, поэтому специалисты от завода часто ездят по стране и ближнему зарубежью. 

Так компания столкнулась с проблемой: процесс оформления командировок, ранее организованный на SharePoint, стал недоступен из-за санкций.

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

Правда, пока вы делаете ремонт по всем правилам СанПин, закупаете оборудование, нанимаете поваров и проходите проверки, деньги уходят в большем объёме, а необходимость обедать в другом месте остаётся. И это плохо.

Но что, если поменять план?

1. Сначала поставим кофемашину и аппарат со снеками в зоне отдыха. Тогда коллеги сократят число подходов «до магазина».

2. Потом отремонтируем помещение, закупим мебель и будем продавать недорогие готовые комплексные обеды. Часть коллектива уже перестанет уезжать на перерыв. 

3. Затем построим свою кухню: часть блюд продолжим закупать, а часть начнём производить сами. Большинство сотрудников это оценит, и люди станут чаще ходить в столовую.

4. Наконец, откроем ещё один цех и перейдём на полный цикл работы.

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

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

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

В этой статье я расскажу, как мы оптимизировали работу колл-центра за счёт интеграции CRM и телефонии, Asterisk IP-АТС и облачной АТС билайн бизнес.

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

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

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

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

Всем привет, меня зовут Андрей Егоров, мне 21 год и я классический junior-разраб, который не мог найти работу. Мне приходилось собирать заказы в «Пятёрочке», чинить телефоны и параллельно продолжать поиски. 

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

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

Мы IT-компания, разрабатываем low-code BPM-систему, и у нас нет штатных юристов. Все наши задачи мы решаем с помощью аутсорс-специалистов, и такой подход кажется нам самым выгодным. Больше трех лет мы работаем с юридической фирмой «Гареев, Махно и Касьян» и взаимодействуем в нашем же продукте.  

По прогнозам Gartner, к концу этого года автоматизация затронет до 50% всего объёма юридических услуг. Поэтому мы попросили коллег рассказать, как ощущается работа в автоматизированной системе — насколько это удобно и как влияет на эффективность выполнения задач.