Диаграмма организационной структуры: порядок в подчиненности и ответственности вместо хаоса

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

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

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

Статья решает задачи:

• собственников и руководителей компаний;
• операционных директоров;
• HR-руководителей;
• руководителей подразделений;
• руководителей проектных офисов;
• бизнес-аналитиков/процессных аналитиков.

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

Оргдиаграмма дает компании прозрачность подчиненности и коммуникаций, навигацию для сотрудников и однозначное распределение ответственности. Но «картинка» устаревает через месяц после утверждения: сотрудники меняются, отделы реорганизуются, проекты появляются и закрываются. Если визуализация не связана с реальными ролями, она превращается в формальный документ, на который никто не обращает внимания. В статье будет рассмотрено, как встроить оргструктуру в систему управления процессами на примере BPM-платформы Stormbpmn.

Почему построение карты бизнес-процессов крайне важно для организации?

Процессы — это то, как именно компания создает ценность. Без карты процессов невозможно увидеть сквозную логику работы, выявить узкие места, назначить владельцев и выстроить управление на основе фактов, а не мнений. Оргструктура и процессы — две стороны одной системы: первая отвечает на вопрос «кто кому подчиняется», вторая — «кто что делает и как это связано». Связь между ними обеспечивает управляемость, прозрачность и готовность компании к изменениям.

Что такое организационная диаграмма и чем она отличается от оргструктуры

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

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

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

Оргдиаграмма должна отвечать на вопросы:

• кто кому подчиняется;
• какие отделы существуют в компании;
• какие уровни управления присутствуют;
• кто является руководителем направления;
• как распределены управленческие функции.

Термины: organigram, org chart, диаграмма оргструктуры

В англоязычных источниках для обозначения оргдиаграмм используют три термина — org chart, organigram и диаграмма оргструктуры. По смыслу они совпадают, но различаются сферой и стилем употребления.

• Org chart — сокращенная форма, самая употребимая в корпоративной среде, в IT и в интерфейсах HR-систем и сервисах для построения моделей. Так называют любую структуру — иерархическую, матричную, плоскую и др.
• Organigram — более редкий вариант, распространен в британском английском и в документах международных организаций. Обычно так называют именно графическое изображение структуры.
• Диаграмма организационной структуры (оргдиаграмма, оргструктура) — русскоязычный эквивалент. В российской практике это чаще официальный документ: его утверждают приказом руководителя и прикладывают к положению об организационной структуре.

Зачем нужна диаграмма организационной структуры предприятию

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

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

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

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

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

Что должна давать оргдиаграмма руководителю и сотруднику

Оргдиаграмма служит одновременно инструментом управления для руководителя и средством навигации для сотрудника.

Ценность для руководителя

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

Ценность для сотрудника

• навигация по компании. Понимание, к кому обращаться по вопросам вне зоны ответственности и какова цепочка согласования;
• карьерные перспективы. Визуализация уровней и должностей для оценки траекторий роста;
• осознание места в системе. Понимание связи своей должности со смежными и обеспечивающими функциями;
• ускорение адаптации. Сокращение времени на понимание оргструктуры в период онбординга.

Виды организационных диаграмм

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

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

Ниже будут подробнее рассмотрены три базовые модели: иерархическая, матричная и плоская. Они отвечают на ключевые управленческие вопросы — «кто кому подчиняется», «как распределять ресурсы между задачами» и «как принимать решения быстро». На практике чистые модели встречаются редко: чаще это гибрид, где базовые модели дополняют друг друга.

Иерархическая организационная диаграмма

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

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

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

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

Матричная организационная диаграмма

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

Матричная структура популярна в IT, консалтинге, R&D и продуктовых компаниях, где важно сочетать экспертизу и проектные задачи. Она обеспечивает эффективное использование ресурсов и высокую адаптивность.

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

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

Плоская организационная диаграмма

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

Как это выглядит: все блоки расположены на одном-двух уровнях, без глубокой вложенности.

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

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

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

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

• высшее руководство — генеральный директор, совет директоров, управляющий комитет;
• первые заместители и исполнительные директора — руководители направлений, замыкающие на себе крупные блоки;
• крупные функциональные блоки — производство, продажи, финансы, HR, IT, логистика;
• прямые связи подчинения — сплошные линии, показывающие административную подчиненность.

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

Что не включать

Не стоит перегружать деталями и добавлять:

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

Избыточная глубина и обилие второстепенных блоков снижают управленческую ценность. Оптимальный формат — размещение на одном экране или листе А3 и получение ответа на вопрос «как устроена компания в целом».

Принципы построения верхнего уровня

Важно соблюдать несколько принципов:

• единообразие. Все блоки одного уровня оформляются одинаково, связи подчинения — однотипно;
• должности, а не люди. Блоки не должны содержать роли или фамилии сотрудников;
• минимально достаточная глубина. Уровень детализации определяется целью: стратегический обзор, реорганизация или процессное управление;
• актуальность. Обновления при каждом структурном изменении, а не раз в год.

Если схема предприятия становится слишком объемной, это сигнал о необходимости вынести часть блоков за ее пределы.

Организационная диаграмма подразделений: когда нужна отдельная схема

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

Когда создается отдельная схема

Отдельная модель подразделения актуальна в следующих случаях:

• численность превышает 10–15 человек. На общей схеме такое количество блоков делает ее нечитаемой;
• есть внутренняя иерархия. Сектора, группы, команды, смены — все это требует отдельного уровня детализации;
• присутствуют должности, которых не видно на верхнем уровне. Например, категорийные менеджеры, аналитики, специалисты по тендерам;
• нет выраженной специфики направлений. Несколько групп деятельности, распределение по регионам, проектным командам или клиентским сегментам;
• требуется зафиксировать зоны ответственности внутри функционального блока. Это важно для процессного управления и распределения KPI.

Что включать в диаграмму подразделения

Детализируется один блок верхнего уровня, который содержит:

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

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

Связь с диаграммой предприятия

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

Это обеспечивает:

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

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

Ограничения и риски

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

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

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

Как построить диаграмму организационной структуры предприятия

Достоверная диаграмма организационной структуры предприятия строится на основе кадровых данных. Источники — штатное расписание, положение об организационной структуре и приказы об изменениях, а также справочник подразделений и должностей из кадровой системы (например, 1С:ЗУП). Удобнее всего сразу работать в Stormbpmn: в инструменте оргструктура связана с процессами, поэтому переноса не требуется.

Шаг 1. Определить цель и границы. Навигация для сотрудников, подготовка реорганизации или процессное моделирование? Цель задает глубину проработки: для навигации достаточно верхнего уровня, для реорганизации и моделирования нужны связанные описания.

Шаг 2. Собрать данные. Сделать выгрузку из штатного расписания или HR-справочника с полями: подразделение, вышестоящее подразделение, должность, руководитель, количество штатных единиц. Именно поле «вышестоящее подразделение» превращает плоский список в дерево. В Stormbpmn такую выгрузку можно загрузить из Excel или CSV — система сама построит дерево оргструктуры.

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

Шаг 4. Построить каркас иерархии. Начать с первого лица и его прямых подчиненных, затем добавлять уровни сверху вниз. Для предприятия показать только крупные блоки, подробности перенести на уровень ниже.

Шаг 5. Добавить связи и зоны ответственности. Административное подчинение показать сплошными линиями, функциональную и проектную связи — пунктирными, с отображением на легенде. В каждом блоке указать руководителя и зону ответственности.

Шаг 6. Проверить типовые ошибки:

• у блока больше одного административного руководителя;
• у руководителя слишком много прямых подчиненных (ориентир — не больше 7–10) — сигнал перегрузки;
• есть подразделения без руководителя или функции без владельца;
• в блоках смешаны должности и фамилии;
• подчинение и горизонтальные связи показаны одинаково, без легенды;
• вместо схемы — список должностей без связей.

Шаг 7. Согласовать и опубликовать. Получить подтверждение от руководителя, опубликовать мастер-версию в одном месте с доступом на чтение для сотрудников и назначить владельца, который будет поддерживать ее в актуальном состоянии. Если оргструктура ведется в Stormbpmn, команда видит ее актуальную версию по ссылке — без рассылки файлов и копий в презентациях.

Как выбрать вид диаграммы под реальную модель управления

Определить подходящий вид помогут три вопроса:

1. Есть ли проектные или продуктовые команды, где сотрудник одновременно подчиняется функциональному руководителю и руководителю проекта? Если да — нужна матричная схема или иерархия с отдельным слоем проектных связей.
2. Сколько уровней управления между первым лицом и исполнителем? Если больше 4–5 — стоит строить иерархию в виде нескольких связанных схем: верхний уровень предприятия и отдельные схемы подразделений.
3. Кто принимает операционные решения — руководители или сами команды? Если команды самоорганизуются, а численность небольшая, подойдет плоская схема.

Отдельный вопрос — выбор инструмента. Stormbpmn позволяет не просто рисовать блоки, а связывать их с ролями в процессах — подробнее об этом ниже.

Как поддерживать актуальность и кто владелец схемы

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

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

Практика 1. Разделять формальную и фактическую структуру

Документы показывают, как структура должна быть устроена. Реальность может отличаться: неформальные каналы коммуникации, дублирующие подчинения, «серые» зоны ответственности. Обе картины фиксируются, а расхождения — это зоны риска, требующие отдельного анализа.

Практика 2. Назначать владельца диаграммы

Без ответственного модель устаревает. Владельцем становится HR-руководитель или бизнес-аналитик, который вносит правки при кадровых и структурных изменениях, проводит регламентную сверку и согласовывает правки с владельцами процессов.

Практика 3. Заводить паспорт диаграммы

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

Практика 4. Хранить мастер-версию в одном месте

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

Практика 5. Согласовывать в два этапа

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

Практика 6. Обновлять диаграмму по регламенту

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

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

Где тут Stormbpmn: связка оргдиаграммы с процессами и ответственностью

Оргдиаграмма отвечает на вопрос «кто кому подчиняется», модель процессов — «кто что делает». Пока эти картины живут отдельно, ответственность распределена только на бумаге: в процессах фигурируют «отдел продаж» и «бухгалтерия», а кто конкретно принимает решение, непонятно. Это две разные модели: оргструктура описывает подразделения и должности, ролевая модель — роли в процессах (исполнитель, согласующий, владелец). Их объединяет назначение: каждую роль закрепляют за конкретной должностью или подразделением.

• Единый справочник ролей. Роли ведут отдельно от оргструктуры: одну роль могут выполнять несколько должностей, а одна должность может совмещать несколько ролей. В процессах используются только те формулировки ролей, которые указаны в справочнике — без произвольных названий вроде «ответственный сотрудник».
• Задачи присваиваются ролям, а не людям. Каждая задача в BPMN-схеме закрепляется за ролью. При смене сотрудника процесс остается прежним: новый человек занимает ту же должность и выполняет закрепленные за ней роли.
• Владельцы процессов — из оргструктуры. Владелец отвечает за результат действий целиком, включая стыки между подразделениями. Как правило, это руководитель, в чьей зоне создается основной результат.
• Ответственность — в матрице RACI. Для каждого шага указывается, какая роль выполняет работу (R — Responsible), отвечает за результат (A — Accountable), консультирует (C — Consulted) и получает информацию (I — Informed). Главное правило: на каждом шаге ровно одна роль с буквой A.

Пример RACI для процесса «Заключение договора с клиентом»:

Матрица сразу показывает провалы ответственности: шаги без A, роли, перегруженные буквой R, и шаги, где «отвечают все».

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

Роли участников процесса в Stormbpmn построены по той же логике, что и RACI: исполнитель (R) выполняет операции процесса, владелец (A) отвечает за результат, согласующий (C) дает экспертную оценку и получает запросы на согласование, информируемый (I) получает сведения об изменениях. Роли привязываются к процессам, а список ролей можно загрузить из CSV.

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

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

Пример организационной диаграммы

Ниже — три типовых примера: иерархическая модель небольшой компании, матрица «функция + проект» и схема одного отдела. Их можно собрать в Stormbpmn и связать должности с ролями в процессах, как описано выше.

Пример 1: иерархическая оргдиаграмма небольшой компании

Иерархическая диаграмма организационной структуры торгово-производственной компании численностью около 40 человек:

Генеральный директор
├─ Коммерческий директор → менеджеры по продажам (5), маркетолог
├─ Руководитель производства → мастер участка, рабочие (20)
├─ Руководитель склада и логистики → кладовщики (2), водители (3)
├─ Финансовый менеджер → бухгалтер
└─ Офис-менеджер → секретарь, курьер

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

Пример 2: матрица «функция + проект»

Проектная компания: по вертикали — функциональные отделы, по горизонтали — текущие проекты. На пересечении — сотрудники, которые работают в проектной команде. Административно сотрудник подчиняется руководителю отдела (сплошная линия), по задачам проекта — руководителю проекта (пунктир).

Пример 3: оргдиаграмма подразделения на примере отдела

Отдел технического контроля (ОТК) производственной компании из 12 человек — то, что на схеме предприятия показано одним блоком:

Начальник отдела технического контроля
├─ Группа входного контроля: ведущий инженер, контролеры входного этапа (3)
├─ Группа операционного контроля: старший контролер, контролеры операционного этапа (4)
└─ Группа приемочного контроля: инженер по качеству, специалист по рекламациям

Схема показывает степень детализации, недоступную на верхнем уровне предприятия: группы внутри отдела и должности в них. Пунктиром можно отметить функциональную связь специалиста по рекламациям с отделом продаж — претензии клиентов поступают к нему через менеджеров.

Заключение

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

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

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

Ключевые выводы

• использовать диаграмму организационной структуры как карту распределения власти и ответственности;
• на уровне предприятия показывать только топ-менеджмент и крупные функции, на уровне подразделения — детализировать до должностей;
• разделять должности и людей. Оргдиаграмма — это модель должностей и подчиненности. Фамилии — в штатном расписании;
• назначать владельца схемы и поддерживать актуальность;
• связывать оргдиаграмму с BPMN-процессами и RACI — тогда управление станет системным;
• строить схему на данных, а не по памяти: источниками должны быть штатное расписание и HR-справочник;
• закреплять ответственность за ролями: в матрице RACI на каждом шаге процесса должна быть ровно одна роль с буквой A.

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

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

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