В большинстве компаний подразделение до сих пор описывается двумя способами. Первый — оргсхема, где есть прямоугольник с названием отдела и стрелками подчинённости. Второй — положение о подразделении, где сказано, что оно «обеспечивает», «контролирует», «сопровождает» и «взаимодействует». Формально этого достаточно: отдел существует, функции перечислены, зона ответственности обозначена.
Но как только возникает практический вопрос — что именно это подразделение обязано делать, по каким правилам, с каким SLA, где проходят границы его ответственности и как проверить исполнение, — оказывается, что в явном виде ответа нет.
Знания хранится в регламентах, в BPM-системе, в локальных договорённостях, в головах сотрудников. Пока команда стабильна, это ещё может работать. Но при росте нагрузки, смене руководителя, цифровизации или попытке встроить в контур AI всё начинает рассыпаться. Новый руководитель читает документы, которые не совпадают с реальностью. Аналитик восстанавливает процесс по кускам. Автоматизация покрывает отдельные сценарии, но не даёт целостной модели того, что именно подразделение обязано гарантировать организации.
Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему привычное описание подразделений перестало работать как управленческий инструмент, как мы подошли к этому через концепцию Организация как Код (OaC) и почему начали описывать подразделения не как функции на оргсхеме, а как исполняемые сервисные контракты.
Почему классическое описание подразделения больше не работает
Если задать несколько прикладных вопросов, классическое описание подразделения очень быстро перестаёт помогать. Что именно внутренний клиент может запросить у отдела? Какой результат он должен получить на выходе? Какой набор данных обязан приложить к запросу? Какие SLA реально действуют? Где проходит граница между тем, что подразделение делает, и тем, чего не делает?
Обычно ответы существуют, но в разрозненном виде. Организация живёт, процессы идут, но формального, проверяемого и исполнимого описания подразделения нет.
Это означает долгий вход в контекст, сильную зависимость от носителей знания и фрагментарность описания. А для AI-агента проблема ещё жёстче: ему мало доступа к документам, нужен машиночитаемый контракт, который отвечает на вопросы. Именно поэтому нам показалось важным сменить сам язык описания организации.
Что такое Организация как код
В нашем подходе Организация как Код (Organization as Code, OaC) подразделение рассматривается как исполняемый сервисный контракт. В нашей модели у подразделения есть две основные стороны.
Сервисы подразделения. Какие запросы оно принимает, от кого, по каким каналам, с каким входным пакетом, в какие сроки и с каким результатом на выходе.
Фоновые обязательства подразделения. То, что должно поддерживаться постоянно: контроль сроков, мониторинг нарушений, регулярные проверки, соблюдение нормативов, отслеживание отклонений.
Дополнительная третья сторона — ресурсы: штат, нагрузка, пропускная способность, зависимости, инструменты, бюджет, то есть всё, без чего сервисные обещания подразделения остаются декларацией.
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 не как на философию, а как на рабочий инструмент, то у него есть довольно прагматичный эффект.
Компания получает более точный язык описания подразделений.
Становится проще отделять реальные обязательства от мифологии. Очень часто подразделение в компании считается ответственным за то, что нигде явно не зафиксировано. При смене людей или росте нагрузки это превращается в конфликт ожиданий. Сервисный контракт позволяет такие разрывы делать явными.
Появляется основа для проверки исполнимости. Если подразделение обещает определённый SLA, это можно связать с ресурсной моделью, входящим потоком и фактической пропускной способностью. Если обязательство сформулировано как инвариант, можно понять, проверяется ли оно вообще, чем именно и что происходит при нарушении.
Организация получает более надёжный мост между управленческой моделью и автоматизацией. Не сначала пишем красивый текст, потом отдельно делаем процесс, потом отдельно объясняем сотрудникам, как всё работает на самом деле, а стараемся строить единый контракт, который живёт сразу в нескольких слоях.
Почему мы считаем это перспективным направлением
Для нас главный вывод оказался довольно неожиданным в своей простоте. Мы не обнаружили, что для OaC нужно изобретать принципиально новую машину исполнения. Наоборот, стало видно, что существенная часть нужной логики уже есть в зрелой BPM-платформе.
Значит, следующая задача — не строить новый мир с нуля, а поднять над существующим слоем исполнения более точный организационный язык. Такой, в котором подразделение можно описывать как исполнимый сервисный контракт, а не как совокупность общих слов, разрозненных настроек и неформальных договорённостей.
И если этот язык получится сделать достаточно строгим для машины и достаточно понятным для человека, то организация впервые начинает описываться не только как схема подчинённости и набор процессов, а как система формализованных обязательств, которые можно наблюдать, проверять и исполнять.
На наш взгляд, именно здесь и начинается настоящий переход от «регламентов о работе» к исполняемой модели организации.
