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

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

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

Почему классическое описание подразделения больше не работает

Классическое описание не отвечает на прикладные вопросы: что именно может запросить внутренний клиент, какой результат он получит, какие данные нужно приложить, какие SLA действуют, где проходят границы ответственности?

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

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

Что такое Организация как Код

В нашем подходе подразделение — это исполняемый сервисный контракт. У него две основные стороны:

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

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

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

Ключевой сдвиг — переход от языка задач к языку инвариантов. Например:

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

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

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

Чтобы сервис можно было потреблять без уточнений, недостаточно фразы вроде «отдел закупок обеспечивает закупочную деятельность». В OaC каждый сервис описывается карточкой с полями:

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

Пример: сервис «Заявка на закупку → PO»

• Результат: Оформленный заказ поставщику, протокол выбора, трекинг поставки.
• SLA: первый ответ — не позднее 4 часов, выпуск PO — до 3 рабочих дней (стандартные запросы), до 1 дня (критичные).
• Входной пакет: описание потребности, категория, сумма, ЦФО, срок.
• Политики: до порога — согласует тимлид, выше — руководитель, ещё выше — CFO; при крупных суммах — несколько коммерческих предложений; приоритет — поставщики из утверждённого списка.
• Граница: не покрывает аварийные закупки без последующего аудита (если не оговорено отдельно).

Такое описание помогает: сотруднику — правильно обратиться, руководителю — понять уровень сервиса, аналитику — проверить соответствие процесса, AI-агенту — получить формальную рамку для действий.

Как выглядит исполняемое обязательство

Фоновые обязанности оформляются как карточка обязательства с пятью элементами:

• Инвариант — условие истинности.
• Триггер — когда проверять: по расписанию, событию, смене состояния.
• Проверка — способ верификации: фильтр, правило, выражение.
• Реакция — действие при нарушении.
• SLO — срок обнаружения или устранения отклонения.

Формулировка «юридическая служба контролирует сроки контрактов» бесполезна для автоматизации. А вот «ежедневно проверять, что нет контрактов с окончанием менее чем через 30 дней без процесса продления; при нарушении создать задачу, уведомить владельца, эскалировать, если задача не создана в течение суток» — уже исполняемо.

OaC переносит на управление логику инженерных систем: есть целевое состояние, проверка, реакция, наблюдаемость.

Почему существующие стандарты не решают задачу

Существуют смежные подходы, но каждый охватывает лишь часть:

• BPMN описывает потоки, но не даёт контракта — нельзя понять, что гарантирует сервис и какие у него фоновые обязательства.
• ARIS синхронизируется с метаданными, но не становится исполнимым контрактом — между моделью и системой остаётся консультант.
• ArchiMate — архитектурный язык, полезен для описания бизнес-сервисов, но не превращает обязательства в проверяемые инварианты.
• ITIL близок к каталогам сервисов, но ограничен IT и не охватывает организационные обязательства.

Если упростить: BPMN и аналоги описывают, как течёт работа, а OaC — что подразделение обязано гарантировать и на каких условиях.

Как OaC реализован на платформе

Мы проверили OaC на практике, сопоставив его с возможностями нашей платформы. Переход выглядит так:

• Описание сервиса → категория процесса.
• Входной пакет → обязательные поля и параметры.
• Результат → конечные статусы и выходные атрибуты.
• SLA → сроки задач, контроль просрочек, эскалации.
• Политики согласования → условия маршрута, матрицы акцепта.
• Исключения → альтернативные ветки маршрута.
• Каналы входа → формы, API, почта, интерфейсы.

Сервисный контракт перестаёт быть абстракцией — он становится рабочей комбинацией маршрутов, состояний, правил и проверок.

По экспертной оценке, стейт-машина «Первой Формы» покрывает около 85% потребностей OaC из коробки. Это не универсальная метрика, а рабочая оценка соответствия модели и возможностей платформы. Главное — OaC не требует экзотической среды: нужная механика уже есть в зрелых BPM-системах с ролями, состояниями, событиями, правилами и автоматикой.

Таким образом, наша платформа становится исполнительным слоем для сервисных контрактов.

Почему OaC важен в эпоху AI

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

OaC — это способ сделать организацию достаточно формальной, чтобы с ней могли работать не только люди, но и программные исполнители.

Прагматичные эффекты OaC:

1. Точный язык описания подразделений.
2. Чёткое разделение реальных обязательств и мифологии. Многие подразделения несут ответственность за то, что нигде не зафиксировано. При смене кадров это вызывает конфликты. Сервисный контракт делает такие разрывы явными.
3. Возможность проверить исполнимость: SLA можно сопоставить с ресурсами, потоком и пропускной способностью; инварианты — с механизмами проверки и реакции.
4. Надёжный мост между управленческой моделью и автоматизацией. Вместо трёх отдельных слоёв — текст, процесс, реальность — появляется единый контракт, живущий сразу в нескольких плоскостях.

Почему это перспективное направление

Главный вывод: для OaC не нужно изобретать новую систему исполнения. Значительная часть логики уже есть в зрелой BPM-платформе.

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

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

На наш взгляд, именно здесь начинается настоящий переход от «регламентов о работе» к исполняемой модели организации.

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

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

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

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

Почему классическое описание подразделения больше не работает

Если задать несколько прикладных вопросов, классическое описание подразделения очень быстро перестаёт помогать. Что именно внутренний клиент может запросить у отдела? Какой результат он должен получить на выходе? Какой набор данных обязан приложить к запросу? Какие SLA реально действуют? Где проходит граница между тем, что подразделение делает, и тем, чего не делает?

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

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

Что такое Организация как код

В нашем подходе Организация как Код (Organization as Code, OaC) подразделение рассматривается как исполняемый сервисный контракт. В нашей модели у подразделения есть две основные стороны.

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

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

OaC не отменяет регламент и не заменяет собой оргструктуру. Он переводит описание подразделения из режима «текст для чтения» в режим «контракт, который можно проверять, сопоставлять с конфигурацией системы и частично связывать с исполнимой конфигурацией платформы».

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

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

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

Чтобы внутренний сервис можно было реально потреблять без дополнительных объяснений, одной фразы вроде «отдел закупок обеспечивает закупочную деятельность» недостаточно. В OaC каждый сервис оформляется в виде карточки с набором полей. В неё входят:

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

Если взять условный сервис закупок, описание может выглядеть так:

Сервис «Заявка на закупку → PO»

Результат: Оформленный заказ поставщику, протокол выбора и трекинг поставки.

SLA: первый ответ не позднее 4 часов, выпуск PO — до 3 рабочих дней для стандартных запросов и до 1 рабочего дня для критичных.

Входной пакет: описание потребности, категория закупки, сумма, ЦФО, желаемый срок.

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

Граница: сервис не покрывает аварийную закупку без последующего аудита, если это не описано отдельным правилом.

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

Как выглядит обязательство, которое можно исполнять

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

• Инвариант задаёт условие истинности.
• Триггер определяет, когда его проверять: по расписанию, по событию, при смене состояния.
• Проверка описывает способ верификации: фильтр, правило, выражение, метрика, запрос.
• Реакция определяет действие при нарушении.
• SLO задаёт, в какой срок отклонение должно быть обнаружено или отработано.

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

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

Почему существующие стандарты не закрывают эту задачу полностью

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

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

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

• ARIS и историческая связка ARIS → ERP-системы были ближайшим прецедентом. Но там модель в основном синхронизировалась с метаданными, а не становилась прямым исполнимым контрактом. Между моделью и работающей системой по-прежнему стоял консультант.

• ArchiMate даёт язык архитектуры enterprise и полезен для описания бизнес-сервисов и контрактов на уровне архитектуры. Но это именно архитектурное описание, а не исполнимый слой обязательств с реакцией на нарушение.

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

Если упростить до одной формулы, то BPMN и близкие подходы в основном описывают то, как течёт работа, а OaC пытается формализовать, что подразделение обязано гарантировать и на каких условиях.

Как мы примерили OaC к реальной платформе исполнения

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

Мы сделали инженерную карту понятий OaC на сущности нашей платформы. Вот как выглядит этот переход:

• Описание сервиса → категория процесса.
• Входной пакет → набор обязательных полей и параметров, без которых задача не может быть корректно создана или переведена дальше.
• Результат → конечные статусы и выходные атрибуты процесса.
• SLA → сроки задачи, сроки шага, контроль просрочки и правила эскалации.
• Политики согласования → условия маршрута, матрицы акцепта, правила делегирования и возврата на доработку.
• Исключения и аварийные сценарии → альтернативные ветки маршрута.
• Каналы входа → формы, API, почту, пользовательские интерфейсы и другие стандартные способы запуска процесса.

То есть сервисный контракт перестаёт быть абстракцией и начинает жить в исполнимой системе в виде работающей комбинации маршрута, состояний, правил, сроков и проверок. Результат оказался для нас важным. По экспертной оценке, основанной именно на сопоставлении полей карточки сервиса и элементов обязательств с существующими сущностями платформы, стейт-машина «Первой Формы» покрывает около 85% потребностей OaC из коробки.

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

Иными словами, «Первая Форма» в этой логике выступает как исполнительный слой для сервисных контрактов подразделений.

Почему эта тема стала актуальной в контексте AI

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

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

Если смотреть на OaC не как на философию, а как на рабочий инструмент, то у него есть довольно прагматичный эффект.

1. Компания получает более точный язык описания подразделений.
2. Становится проще отделять реальные обязательства от мифологии. Очень часто подразделение в компании считается ответственным за то, что нигде явно не зафиксировано. При смене людей или росте нагрузки это превращается в конфликт ожиданий. Сервисный контракт позволяет такие разрывы делать явными.
3. Появляется основа для проверки исполнимости. Если подразделение обещает определённый SLA, это можно связать с ресурсной моделью, входящим потоком и фактической пропускной способностью. Если обязательство сформулировано как инвариант, можно понять, проверяется ли оно вообще, чем именно и что происходит при нарушении.
4. Организация получает более надёжный мост между управленческой моделью и автоматизацией. Не сначала пишем красивый текст, потом отдельно делаем процесс, потом отдельно объясняем сотрудникам, как всё работает на самом деле, а стараемся строить единый контракт, который живёт сразу в нескольких слоях.

Почему мы считаем это перспективным направлением

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

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

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

На наш взгляд, именно здесь и начинается настоящий переход от «регламентов о работе» к исполняемой модели организации.