Организация как Код: как описывать подразделения как исполнимые сервисные контракты

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