Когда в компании говорят о модели подразделения, обычно имеют в виду что-то вполне привычное: положение об отделе, регламент, SLA, список ролей и зон ответственности. Формально этого достаточно: подразделение описано, обязанности зафиксированы, сроки обозначены.
Но как только возникает практический вопрос — а как это подразделение на самом деле работает изо дня в день, по каким правилам движутся задачи, где реально проверяются сроки, какие данные обязательны на входе и что система делает без участия человека, — быстро выясняется, что документов недостаточно.
Если в компании внедрено ПО для автоматизации, значимая часть настоящей модели подразделения живёт в конфигурации системы: в состояниях, переходах, правах, обязательных полях, автоматизациях, событиях и скрытых технических правилах. Если смотреть только в документы, получится аккуратная управленческая картина. Если смотреть только в конфигурацию, можно увидеть механику, но потерять смысл. Реальное устройство подразделения возникает только на пересечении этих двух слоёв.
В ежедневной рабочей рутине это не проявляется, но если у отдела меняется руководитель, процессы нужно масштабировать на новый филиал или к работе подключается подрядчик, разрыв становится проблемой, и решить её быстро не всегда получается.
Меня зовут Денис Селезнёв, я генеральный директор компании «Первая Форма». Мы занимаемся автоматизацией бизнес-процессов уже более 20 лет. В последнее время мы активно развиваем новый подход к оцифровке бизнесов — Организация как код, о нём я рассказывал вот в этой статье. В рамках OaC мы решили взять живую конфигурацию, извлечь из неё формальную модель подразделения и сравнить её с тем, что написано в регламенте. Эта статья — о том, что получилось.
Почему модель подразделения живёт сразу в двух местах
Во многих компаниях организационная модель существует как минимум в трёх версиях:
Первая — нормативная.Это положения, регламенты, инструкции, SLA и прочие документы, которые отвечают на вопрос, как всё должно работать.
Вторая — исполнимая.Это то, как подразделение реально выражено в системе: категории, состояния, маршруты, обязательные поля, права, события, автоматические действия, ограничения и служебная логика.
Третья — ментальная.Это то, как процессы понимают сотрудники. Часто они ищут более простые или компромиссные пути выполнить задачу, имеют собственные договорённости и выгоды, из-за которых идут по совершенно иным путям.
Проблема в том, что эти слои почти никогда не совпадают автоматически. Документ может быть абсолютно корректным по смыслу, но не отражать актуальную конфигурацию. Система, в свою очередь, может содержать важную логику, которая нигде в документах вообще не описана, или в корпоративной среде процесс настроен по устаревшим шагам и сотрудникам каждый раз приходится корректировать его вручную. А версия процесса в головах сотрудников может не совпадать ни с одним зафиксированным слоем.
Пока всё держится на людях, это не всегда заметно. Руководитель знает, как устроен процесс, команда привыкла к нюансам: где нужно заполнить дополнительное поле, на каком шаге срок пересчитывается неочевидным образом и почему задача вдруг вернулась в работу. Но как только начинается аудит, редизайн процесса, передача знаний или попытка формализовать работу для автоматизации, разрыв между документом и системой становится очень заметным.
Зачем мы переводили это в YAML
Чтобы сравнение не сводилось к ручной сверке и спорам уровня «кажется, тут не совсем так», нужен был общий формат. Мы использовали YAML как машиночитаемое представление модели подразделения. Оно позволило сопоставлять поля, искать недостающие элементы, выделять расхождения по классам.
Здесь не было задачи «сделать всё модным и кодоподобным». Нам нужен был формат, который одновременно решает две задачи. С одной стороны, он должен быть достаточно строгим, чтобы вместить сервисы, роли, SLA, входные пакеты, состояния, права и автоматизации. С другой — достаточно читаемым, чтобы с ним мог работать аналитик, владелец процесса или руководитель подразделения.
В результате у нас появились две версии одной и той же сущности.
- Document-based YAML, собранный из нормативных материалов. Это модель того, как подразделение должно работать. В ней собраны инструкции, регламенты, ЛНА, организационная схема команды.
- Extracted YAML, собранный из живой конфигурации. Это модель того, как подразделение реально реализовано в системе, его операционные функции. В неё попали состояния и маршруты, переходы, дополнительные параметры, обязательность полей на переходах, права на категории, группы и роли, а также автоматизации и событийная логика.
Это важный момент. Если ограничиться только маршрутом и перечнем полей, вывод получится слишком поверхностным. Настоящая операционная логика подразделения находится глубже — в том, какие поля становятся обязательными на конкретном шаге, кто вообще видит нужную категорию, какие действия срабатывают по событию и какие части процесса выполняются без участия человека. Такая модель показывает, как работает подразделение в реальности в мелких деталях.
Как только обе модели оказываются в одном формате, между ними появляется не абстрактное ощущение несоответствия, а вполне конкретная разница. Можно проверить, совпадают ли категории, одинаково ли понимается входной пакет, где именно реализован SLA, какие правила существуют только в документах, а какие — только в конфигурации.
И в этот момент разговор о модели подразделения перестаёт быть чисто описательным и становится проверяемым.
Пилот на технической поддержке
Техподдержку для теста мы взяли не просто так. С одной стороны, у этого отдела обычно есть формализованные правила: понятные SLA, типовые входные данные в запросах, категории обращений, ожидаемые сроки реакции и выполнения. С другой — на неё часто нарастает плотный слой исполнимой логики: обязательные поля, возвраты, проверки, автоматические переводы, события, пересчёт сроков, реакции на исключения.
Техподдержка хорошо показывает, насколько документная картина совпадает с тем, что реально происходит в системе. Если между ними есть разрыв, он проявляется быстро и довольно наглядно.
Первое расхождение: SLA в документе есть, а в маршруте его как будто нет
В документах вопрос SLA выглядел понятно: срок реакции — 60 минут, срок выполнения — от нескольких часов до десятков дней в зависимости от приоритета. Для человека, который читает регламент, картина выглядит завершённой.
Но когда мы посмотрели на живую конфигурацию, оказалось, что в стандартных полях маршрута сроки явно не заданы:TermMinutesна шагах был пустым.
Многие системы для автоматизации аудита по инерции ищут срок именно там, где его логично ожидать, и поэтому получают ложную картину. Если остановиться на этом месте, очень легко сделать неверный вывод, что SLA в системе вообще не настроен. Но в реальности он просто жил в другом техническом слое и был реализован через автоматизации и дополнительные параметры, а не через штатный крайний срок шага.
Это важное практическое наблюдение. Поверхностная проверка может показать, что срока как будто нет, хотя в системе он реально исполняется. Просто не тем способом, который ожидает увидеть аналитик при стандартном аудите.
Второе расхождение: разные языки описания входного пакета
В регламенте он был описан на понятном бизнес-языке: описание проблемы, шаги воспроизведения, приоритет, клиент. Это естественный способ объяснить человеку, какая информация нужна, чтобы начать работу.
В extracted-модели процесс оказался гораздо сложнее: появилась необходимость указывать компанию, причину, что сделано, а также другие параметры, часть из которых становилась обязательной только на отдельных переходах. По сути это всё нужно, но исполнители, которые работают по регламенту, часто не готовы сразу заполнить все данные.
И если для сотрудников эта разница не так уж критична, всегда можно потратить пять минут на поиск, то для аналитики и аудита она важна. Если сравнивать два слоя напрямую, без промежуточного маппинга, они почти неизбежно будут казаться противоречивыми. Но на деле регламент описывает, какая информация нужна специалисту для понимания ситуации, а система требует, чтобы эта информация была разложена по структуре, достаточной для маршрутизации, контроля и автоматических действий.
При этом были и более жёсткие случаи, когда документ почти не фиксировал обязательные требования ко входу, а система уже требовала их вполне однозначно. И вот это уже настоящий разрыв между тем, как подразделение описано, и тем, как оно работает на практике.
Третье расхождение: значимая часть процесса живёт в автоматизациях
Самый сильный эффект дало сравнение по автоматизациям.
В document-based модели этот слой либо отсутствовал, либо был описан очень обобщённо. Зато в extracted-модели на трёх категориях технической поддержки обнаружилось 107 правил автоматизации.
Это не второстепенные настройки и не декоративная логика. Именно здесь скрывается значимая часть реального поведения процесса: пересчёт SLA, автозакрытие, возврат в работу, автоматические комментарии, проверки условий, действия до и после шага и другие сценарии, которые влияют на ежедневную работу подразделения.
На бумаге процесс почти всегда выглядит как последовательность ролей, решений и ручных действий. Но в живой системе существенная часть поведения формируется тем, что происходит автоматически, что система проверяет сама, что проставляет сама, что блокирует и что инициирует. Если в регламентах эти детали не зафиксированы, сотрудник, особенно новый, узнает о них только на реальных задачах, и ему придётся привыкать, а общая модель подразделения окажется неполной.
Что это дало на практике
У такого подхода оказался не только исследовательский, но и вполне прикладной эффект. Он даёт аналитику быстрый способ увидеть, где документная модель уже устарела или описывает процесс слишком общими мазками, а также помогает владельцу процесса посмотреть на подразделение не как на набор регламентов, а как на реально исполняемую операционную конструкцию. С такой моделью уже можно улучшать процесс дальше.
Кроме того, оцифрованная модель позволяет отделить три разных типа знания: что зафиксировано в документах, что реально настроено в системе и что всё ещё живёт только в головах экспертов. Это превращает аудит и compliance-проверку из разовой ручной ревизии в воспроизводимую процедуру.
На более широком контуре этот подход тоже показал свою полезность. По десяти подразделениям было сформулировано 80 вопросов, и 41 из них удалось закрыть без интервью, только за счёт документации, метрик, договоров и анализа конфигурации. Это не отменяет разговоры с руководителями, но делает их заметно более предметными. Интервью нужны для прояснения контекста, ограничений и причин принятых решений.
Главный вывод здесь довольно простой: вопрос «где хранится модель подразделения?» сам по себе поставлен неверно, если ожидать один источник правды. Настоящая модель появляется только в момент сверки.
Для нас главный результат этой работы был не в том, что мы смогли собрать YAML-модель из живой конфигурации. Это полезно, но само по себе ещё не даёт основной ценности.
Главное — что формальное сравнение document-based и extracted-модели быстро показывает разрывы в самых чувствительных местах процесса. Именно там, где ошибка особенно дорого обходится бизнесу: в сроках, входных требованиях и автоматизациях. Сам метод reverse extraction позволяет регулярно сверять задекларированную и действительную модель подразделения и замечать расхождения до того, как они превращаются в управленческую проблему. Эти данные можно применить для разных нужд:
- актуализировать процессы;
- найти новые возможности для упрощения и автоматизации;
- реализовать OaC-подход и ввести инварианты — правила, которые будут соблюдаться несмотря ни на что и о нарушении которых система сможет проинформировать;
- внедрить ИИ-агентов и ассистентов, которые смогут выполнять задачи по действующим алгоритмам без ошибок и сложностей, чем сэкономят множество ресурсов живых сотрудников.
В этом смысле настоящая модель подразделения — это не один документ и не один экран админки. Это результат аккуратного сопоставления нескольких слоёв реальности.
