Привет, Хабр! Я — Стас Макаров, ранее продуктовый аналитик в Haulmont, ныне свободный вайбкодер))

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

Очевидная же вещь: задачи исполнителям в процессе надо назначать не по юзернеймам, а по их положению в организации. Исполнители это не Миша, Вася, Петя, а работник склада, менеджер, директор или кто его на данный момент замещает.

Практически во всех лоукод-системах оргструктра есть часть базовой функциональности, но в инженерных BPM на базе движков Camunda или Flowable такой фичи по умолчанию нет. Это довольно странно, поскольку оба два этих вендора не просто делают движки, но поставляют полноценные платформы для энтерпрайз-решений, где это оргструктура однозначно востребована — но нет. Хотя у их младших собратьев по цеху, Bizagi и Bonita, оргструктры реализованы весьма неплохо.

В общем, в Jmix BPM, которым я занимался, тоже оргструктры не было. Все говорили, что хорошо бы сделать, но когда прикидывали стоимость разработки, так энтузиазм пропадал. Увы, против экономики не попрешь!

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

Явление вайбкодинга

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

Тут надо сказать пару теплых слов про Jmix. Если коротко, его уникальность в том, что даже аналитик может собрать Spring Boot приложение с нормальным интерфейсом на Vaadin, не написав ни строчки кода на Java. Пусть это будут только CRUD-экраны, но это будет работающий прототип с живыми данными, а не слайды Power Point и не эскизы в Figma. А если аналитик имеет в бэкграунде инженерный опыт, то он может делать и более продвинутые вещи без помощи "настоящих" разработчиков — которые всегда заняты.

Сначала я пошел вполне традиционным путем: написал ТЗ, проработал модель данных, создал сущности, сгенерил стандартные экраны и допилил UI как мне было нужно.

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

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

И тут я познакомился с Cursor. Это полностью поменяло расклад. Теперь мы могли продвигаться гораздо быстрее. Так я стал вайбкодером))

Вы спросите, почему не Claude, он же вроде самый крутой, про него только и говорят.
Все просто: геополитика.

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

Конечно, я припозднился. Надо было раньше переходить к кодингу с агентом, а не с веб-ассистентом. Всему виной удобство — когда сидишь в своей уютненькой IDE-ешечке, да еще поверх нее почти лоукод-тулзы для модели данных и UI, так не хочется покидать зону комфорта...

Забегая вперед

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

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

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

Но тут пришла мысль: если у нас уже есть оргмодель, которая определяет, что данный сотрудник может и должен делать, то какая разница, человек это или агент?

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

И третья ключевая идея: чтобы ИИ действительно работал в агентском режиме, а не просто был бы встроенным чат-ботом с LLM, ему нужны инструменты — так пусть это будут процессы! То есть, agent tool = process! При этом мы получаем полную унификацию исполнения, наблюдаемость и расширяемость.

Какую боль это снимает:

• Все хотят использовать агентов, но все опасаются пускать их внутрь корпоративного контура — что совершенно правильно.

• Мы даем агенту права доступа и инструменты в виде процессов — тогда вся его деятельность ведется в строгих рамках и полностью отслеживается.

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

Ну а теперь давайте по порядку...

От оргструктры к оргмодели

Изначальная цель была предельно простой — чтобы в BPMN-модели процесса можно было указать исполнителем не конкретного пользователя (пусть даже его юзернейм вычисляется каким-то алгоритмом), а должность в конкретном отделе.

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

Вуаля и дело в шляпе? — Ан-нет! Кто у нас в организации владеет оргструктурой? — Правильно, HR. Значит, всякая система, которая заявляет, что она работаем с оргструктурой, должна быть потенциально совместима с основными HR-приложениями, допустим, SAP и 1С. При этом надо поддерживать не только иерархические, но и плоские структуры типа команд и рабочих групп. Также, хотелось совместимости с другими BPM-системами, где эта функциональность уже есть, например, Bizagi. Еще надо учесть, что сотрудники могут не только занимать несколько должностей, но и в разных организациях, что эти организации могут образовывать холдинг или группу компаний.

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

Имею ли я право?

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

Работает это как показано на рисунке:

• Роль может ассоциироваться с организацией в целом, подразделением, должностью , командой/группой или даже конкретным сотрудником (в некоторых сценариях это удобнее, чем строгий формализм).

• Далее, система собирает все роли, которые сотрудник получает через назначения на должности (через них получаем подразделения и организации) и членство в командах/группах.

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

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

Кстати, даже если у вас нет никаких процессов, и не используется BPM, управление правами через оргмодель ценно и само по себе. Это значительно упрощает администрирование системы.

В принципе, назначение прав доступа через оргмодель с использованием наследования (по департаменту, отделу, должности, группе) — это широко распространенная практика в корпоративных системах, использующих RBAC-подход. Например, в 1С, Bitrix24 и других.

На уровне монолитного приложения реализовать эту идею получилось относительно просто — теперь можно вычислять права каждого сотрудника из организационного контекста и посмотреть, откуда они пришли:

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

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

Аккаунтов много, а человек один

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

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

Ценой был довольно глубокий рефакторинг — пришлось сделать дополнительный слой для представления систем-источников (source systems), чтобы связать сотрудника с его аккаунтами и правами в них.

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

Логика здесь такая:

• Оргмодель получает из удаленной системы список пользователей и список ролей.

• Администратор выполняет маппинг пользовательских аккаунтов на сотрудников и устанавливает связи элементов оргмодели с ролями

• Оргмодель выполняет назначение ролей пользователям в удаленной системе

Если API системы-источника позволяет управлять пользователями и ролями, то вообще никаких изменений в нее вносить не требуется, все делается на стороне оргмодели. Для начала были сделаны интеграции с удаленной системой на том же Jmix и BPM-движком Camunda 7. Общий паттерн определен, дальше — дело техники.

— Да но почему здесь Keycloak? Это же другое!

Оргмодели Keycloak нужен как identity provider, чтобы не гадать, кто есть кто в разных системах: появляется один стабильный userId, один набор атрибутов и единый способ их получить (через токен), которому все доверяют. Но это пока в планах.

DSL для оргмодели

Логически с оргмоделью как бы все понятно — выбрать всех сотрудников отдела X и назначить им роль Y. Или Выбрать всех сотрудников, которые состоят в группе A и имеют скилл B. Или выбрать просто всех сотрудников организации O1. Или найти начальника департамента D3.

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

Что же делать? — Эврика! — Пусть будет специальный язык для резолвинга сотрудников из оргмодели. Тогда можно определять все эти выборки очень естественно и наглядно.

Например, все сотрудники организации Супер Сервис не включая дочерних организаций:

select:
  organization: SUPER_SERVICE
  includeSubOrganizations: false
sourceSystem: LOCAL

Или руководитель технического департамента той же Супер Сервис:

select:
  organization: SUPER_SERVICE
  unit: TECH_DIVISION
  leadershipRole: HEAD
sourceSystem: CAMUNDAselect:
  organization: SUPER_SERVICE
  unit: TECH_DIVISION
  leadershipRole: HEAD
sourceSystem: CAMUNDA

Или Java-разработчики со знанием Java — как это ни смешно. (На самом деле хотел еще добавить уровень скилла, но не успел — тогда бы это было актуально.)

select:
  organization: ACME
  position: JAVA_DEV
  skills:
    - JAVA
sourceSystem: LOCAL

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

Оргмодель: что в итоге

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

Если что, это не строго по нотации, просто для общего представления, как система устроена.

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

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

Продолжение следует:

Часть 2. Процессы: чего до сих пор не хватало обычным BPM

Часть 3. Агенты выходят на работу

Подпишитесь на канал Agentic Enterprise — про жизнь агентов в кровавом энтерпрайзе