Swimlane Diagram (Диаграмма дорожек)

Клиент оформляет заказ, менеджер по продажам передаёт его в обработку, оттуда он уходит в бухгалтерию, затем на склад и в отгрузку. В каждом отделе люди работают добросовестно, а заказ всё равно задерживается. Чаще всего это происходит не внутри отдела, а на переходе между ними: информация теряется, задача ни за кем не закреплена, или каждая из сторон считает, что ход за соседями. Swimlane diagram (диаграмма дорожек) делает такие переходы видимыми. Каждому участнику процесса отводится своя полоса, шаги ставятся в полосу того, кто их выполняет, и каждая стрелка, пересекающая границу полосы, показывает момент смены ответственности.

Хороший пример — работа А. Эшкрафт, Д. Оуэн и В. Рэгсдейл 2025 года «Swimlane: Clinical Workflow Redesign in the Nursing Home». Авторы применили диаграмму дорожек в доме престарелых. Сначала они описали текущий рабочий процесс ухода за пожилыми людьми по данным наблюдательного исследования, одобренного этическим комитетом (IRB). Затем на его основе спроектировали идеальный процесс. По их оценке, уход в таком учреждении за жизнь понадобится 70% пожилых людей, поэтому перестройка рабочих процессов там остаётся недоиспользованным навыком. Схема работы та же, что и в бизнесе: карта «как есть», поиск сбоев на стыках, карта «как должно быть».

Ниже разобраны история метода от многоколоночных схем 1940-х до BPMN 2.0, правила построения дорожек, данные исследований (они скромнее, чем принято считать), типовые ошибки и пятинедельный план. Последний раздел показывает, как пройти этот план во фрейме OrgDevTools.

Происхождение и исследовательская база Swimlane Diagram

У диаграммы дорожек нет одного автора и одной даты рождения. Это результат нескольких линий: инженерной (схемы технологических процессов), управленческой (анализ межфункциональных процессов), программной (средства моделирования) и стандартизационной (нотации BPMN и UML). Из-за этого у метода много названий: swimlane diagram, swim lane map, кросс-функциональная блок-схема (cross-functional flowchart), функциональная карта процесса (functional process map), диаграмма Раммлера — Брейча (Rummler-Brache diagram).

Многоколоночные схемы 1940-х годов

И Lucidchart, и Википедия возводят метод к 1940-м. Тогда появилась разновидность ранних схем технологического процесса (flow process chart) — многоколоночные схемы (multi-column process charts). Обычная схема показывала цепочку операций сверху вниз. Многоколоночная разносила эти операции по столбцам, и каждый столбец означал исполнителя или участок. Тем самым к последовательности шагов добавилось второе измерение: кто именно выполняет шаг. На этой идее держится весь метод.

Гири Раммлер и Алан Брейч: процесс поверх оргструктуры

Популярным и управленческим инструмент сделали Гири Раммлер (Geary Rummler) и Алан Брейч (Alan Brache) в книге 1990 года. Википедия пишет, что именно они назвали такие схемы Swim Lane diagrams. Поэтому Lucidchart использует второе название — «диаграмма Раммлера — Брейча».

В пересказах книга называется по-разному. Lucidchart даёт заголовок «Improving Processes», Википедия — «Improving Performance». Правильное название — «Improving Performance» (1990), его мы и используем.

Раммлер и Брейч рассматривали организацию через сквозные процессы, а не только через иерархию отделов. Диаграмма дорожек подходит для этого как нельзя лучше. Оргструктура отвечает на вопрос, кто кому подчиняется. Дорожки показывают, как работа проходит сквозь подразделения и где она переходит из рук в руки. Подробнее о сквозных процессах — в методике End-to-End Process.

Программные инструменты и сам термин

В Википедии указано, что форма представления «дорожками» развивалась в начале 1980-х, ещё до книги Раммлера и Брейча. Имя автора в нашей выдержке обрезано, поэтому мы его не приводим. В компьютерное моделирование процессов дорожки, по той же статье, ввела компания iGrafx: в 1993 году она добавила их в свой инструмент, а в 1996 году зарегистрировала Swimlane как товарный знак.

Есть и вторая версия происхождения термина. Слово swimlane используется в графическом дизайнере процессов JBoss jBPM, на языке описания процессов jPDL (Process Definition Language). Lucidchart тоже упоминает это значение в компьютерной инженерии. Термин дошёл до массовой аудитории двумя путями: через консалтинг и через ИТ-инструменты для описания рабочих потоков.

Дорожки в BPMN 2.0 и UML

Сегодня дорожки чаще всего встречаются как элемент более строгих нотаций. В BPMN 2.0 (Business Process Model and Notation) процесс помещают в «пул» (pool), который делится на «дорожки» (lanes) по ролям или подразделениям. Lucidchart поясняет: если сложный процесс документируют в BPMN 2.0, на диаграммах технологического процесса (PFD) или в других специальных нотациях, сбор данных обычно поручают команде, знающей эти методы. Дорожки тогда становятся одним из элементов модели. В UML есть диаграмма деятельности с дорожками (activity diagram with swimlanes), которой разработчики разделяют действия между компонентами системы или ролями пользователей. В инструментах «диаграмма как код» дорожки тоже стали отдельным типом: в Mermaid синтаксис swimlanes появился в версии 11.16.0, оформление по умолчанию обновлено в версии 12.0.0.

Практическая линия: бережливое производство и здравоохранение

Самое полезное для практика описание есть в методичке Департамента здравоохранения Миннесоты на основе материалов Minnesota Enterprise Lean. Построение там разбито на два шага. Первый — «пройти процесс» (walk the process) от начала до конца, задавая вопросы о движении информации. Второй — «охарактеризовать процесс»: какие формы, экраны и программы используются на каждом шаге и сколько он длится. В методичке приведена карта с кайдзен-сессии 2012 года, которая заняла стену во всю длину комнаты, и прямо сказано, что многие карты ещё длиннее. Связь с кайдзен здесь прямая: дорожки служат рабочим полем сессии, на котором команда видит текущее и будущее состояние.

В клинической практике, помимо работы Эшкрафт и соавторов, в нашей подборке есть исследование А. Куп, Дж. Коуделл и Н. Пателя (2019). Многопрофильная команда медсестёр приёмного отделения и терапевтов улучшала соблюдение рекомендации ставить пациентам с желудочно-кишечным кровотечением два венозных катетера большого диаметра. Из 100 таких пациентов, госпитализированных в 2017 году, рекомендацию выполнили лишь для 14. Команда работала по циклу DMAIC из арсенала Lean Six Sigma. Аннотация не уточняет, какие диаграммы использовались. Пример показывает другое: тип задачи, где ответственность распределена между двумя профессиональными группами и легко «повисает» между ними.

Что показывают академические работы

Самая важная для метода работа — исследование Ананда Джеярая и Вики Саутер «Validation of Business Process Models Using Swimlane Diagrams» (2014). Авторы начинают с неудобного наблюдения. Диаграммы дорожек принято считать важным инструментом согласования бизнес-правил и процедур с заинтересованными сторонами, потому что они якобы передают информацию о модели процесса эффективно. Но эмпирической поддержки у этого допущения нет: исследований, оценивающих их действенность, в литературе не было. Авторы провели два исследования, в которых студенты разбирали процессы на диаграммах с дорожками и без них. Ценность работы прежде всего в постановке вопроса: популярное убеждение о наглядности дорожек долго оставалось непроверенным.

Ещё две работы дают контекст. Н. В. Абу Бакар, Ш. Муса и А. Х. Мохамад (2020) сравнили диаграммы для моделирования требований — диаграмму вариантов использования, диаграмму деятельности, BPMN — с дорожками на примере ERP-системы. Это линия инженерии требований на основе моделей (MBRE): дорожки там служат способом согласовать, кто что делает в будущей системе. Стивен Алтер (2007) предложил таблицы ответственности за сервис (Service Responsibility Tables) — простой табличный инструмент для анализа и проектирования сервисных систем в рамках метода рабочих систем. Это альтернатива тем, кому удобнее распределять ответственность в таблице, а не на схеме.

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

Ключевые идеи и принципы Swimlane Diagram

Диаграмма дорожек относится к семейству карт процессов (см. Process Mapping). Выделяет её одна идея: шаги размещаются не просто по порядку, а на территории ответственного. Ниже — элементы и правила, из которых складывается рабочая диаграмма.

1. Принцип: блок-схема отвечает на «что», дорожки — на «кто»

   Обычная блок-схема (flowchart) показывает последовательность шагов и развилки. Диаграмма дорожек добавляет второе измерение — исполнителя. Figma в своём FAQ формулирует это различие так: блок-схема описывает поток работы, дорожки показывают, кто что делает. Практическое следствие: блок-схема годится для логики одного исполнителя, а там, где работа переходит между людьми и отделами, нужны дорожки. Если в процессе один участник, дорожки не нужны.

2. Принцип: состав элементов диаграммы

   Lucidchart и ProjectManager описывают одинаковый набор элементов:

   • Дорожка (lane). Горизонтальная строка или вертикальный столбец с названием участника: отдела, роли, внешней стороны (клиент, поставщик) или ИТ-системы. Ориентация зависит от вкуса и формата листа. Горизонтальные удобнее для длинных процессов на широком экране, вертикальные — для печати.

   • Шаг (действие). Прямоугольник с глаголом: «проверить заявку», «выставить счёт».

   • Решение. Ромб с вопросом и ветками «да/нет».

   • Начало и конец. Событие, запускающее процесс, и результат, которым он завершается.

   • Стрелка потока. Порядок шагов. Стрелка, пересекающая границу дорожки, — особая, о ней ниже.

   • Документы, данные, задержки. Дополнительные символы. Методичка из Миннесоты советует выделять цветом задачи, действия и задержки.

3. Принцип: одна дорожка — один вид ответственности

   В рекомендациях Mermaid первое правило звучит так: каждая дорожка должна означать один вид принадлежности (make each lane mean one kind of ownership). Нельзя смешивать на одной диаграмме дорожки «Отдел продаж», «Иванов» и «CRM», если не понятно, что они означают. Выберите основание и держитесь его: подразделения, роли или системы. Если важны и роли, и системы, лучше сделать две диаграммы разного уровня или явно разделить человеческие и системные дорожки. Смешанная дорожка скрывает главный вопрос: кто отвечает за шаг.

4. Принцип: подписанная межполосная передача (handoff)

   Каждая стрелка, пересекающая границу дорожки, — точка передачи ответственности. Mermaid советует подписывать такие передачи (label cross-lane handoffs): что именно передаётся (заявка, согласованный договор, файл) и в каком виде. Неподписанная стрелка выглядит понятно, но не говорит, ушёл ли по ней звонок, письмо или запись в системе. Именно здесь возникают типичные разрывы:

   • Передача без получателя. Стрелка выходит из дорожки, но непонятно, в какую дорожку она приходит.

   • Передача без сигнала. Получатель не знает, что работа пришла, и узнаёт об этом при эскалации.

   • Передача с потерей формы. Информацию переписывают из одного формата в другой. Методичка из Миннесоты спрашивает об этом прямо: «появляется новая информация или её переводят в другую форму?»

   • Передача туда-обратно. Работа ходит между двумя дорожками на доработку, и на диаграмме это видно как зигзаг.

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

5. Принцип: решение стоит там, где его принимают

   Ещё одно правило Mermaid — ставить решения туда, где их принимают (put decisions where they are made). Если ромб «Одобрить скидку?» нарисован в дорожке продаж, а решает финансовый директор, диаграмма врёт о распределении власти. Перенос решения в нужную дорожку часто сам по себе обнажает проблему: появляются две лишние передачи туда и обратно и ожидание, о котором раньше не говорили.

6. Принцип: сначала пройти процесс, потом рисовать

   Lucidchart выносит в отдельный раздел то, как собирать данные для диаграммы Раммлера — Брейча: сначала изучить процесс, потом рисовать. Методичка из Миннесоты называет этот шаг «пройти процесс» и предлагает вопросы для каждого шага:

   • Откуда приходит эта информация?

   • Шаг выполняется без перерыва или с прерываниями?

   • Бывает ли, что информации не хватает или она неверна?

   • Куда информация идёт дальше? Есть ли у неё больше одного адресата?

   • Это новая информация или её переводят в другую форму?

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

7. Принцип: охарактеризовать каждый шаг

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

8. Принцип: две диаграммы — «как есть» и «как должно быть»

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

9. Принцип: совместное построение

   Figma завершает описание шаблона советом не делать диаграмму в одиночку (don't go at it alone). Причина практическая. Каждый участник хорошо знает свою дорожку и плохо знает чужие, а разрывы находятся как раз на границах. Человек из одного отдела нарисует свою часть подробно, а соседние — по догадке. SlideModel отдельно называет пользой метода сплочение межфункциональных команд (fostering collaboration): совместная диаграмма становится общим языком, на котором отделы договариваются о передачах.

10. Принцип: читаемость и уровни детализации

    Mermaid советует держать длинные процессы читаемыми (keep long processes readable) и использовать устойчивые идентификаторы шагов (use stable IDs), чтобы диаграмму можно было обновлять без поломки ссылок. На практике это означает уровни: верхний — 5–7 дорожек и крупные этапы, нижний — отдельные диаграммы для проблемных участков. В Mermaid есть и раздел о том, когда лучше выбрать другую диаграмму (when to use another diagram). Если ответственность не меняется, хватит блок-схемы. Если важна матрица «кто утверждает, кто консультирует», нужна RACI-матрица. Если нужен только контур процесса, подойдёт SIPOC.

11. Принцип: где метод применяют

    Конкуренты называют одни и те же сферы. SlideModel перечисляет управление бизнес-процессами (BPM), управление проектами, разработку ПО, картирование клиентского пути (customer journey mapping), комплаенс и управление рисками, стратегические решения и производственные процессы. ProjectManager называет пользователей: руководители проектов, бизнес-аналитики при картировании процессов, операционные менеджеры на производстве, генподрядчики в строительстве, фирмы профессиональных услуг при работе с клиентом. Общий признак во всех случаях — процесс, который проходит через несколько участников, у которых разное начальство и разные цели.

12. Принцип: инструмент вторичен

    Диаграмму можно нарисовать в Lucidchart, Visio, SmartDraw, Figma (FigJam), Canva или описать кодом в Mermaid. SlideModel объясняет даже, как перенести диаграмму из Visio в презентацию. Готовые шаблоны экономят время на оформление. Но методичка из Миннесоты и сессия кайдзен 2012 года напоминают: первая версия чаще всего рождается на стене из стикеров, где её легко двигать всей группой. Переносить в редактор стоит, когда структура устоялась.

Ограничения, слепые зоны и критика Swimlane Diagram

Типовые ошибки при работе с Swimlane Diagram

1. Ошибка 1: диаграмму рисует один отдел.

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

   Как избежать

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

2. Ошибка 2: смешанные основания дорожек.

   На одной диаграмме встречаются полосы «Продажи», «Петрова», «1С» и «Склад». Непонятно, отвечает ли за шаг человек, отдел или программа. Когда шаг стоит в дорожке системы, ответственность размывается: «это система не отправила». На деле кто-то должен был проверить, что отправка произошла.

   Как избежать

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

3. Ошибка 3: рисуют регламент, а не реальную работу.

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

   Как избежать

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

4. Ошибка 4: одна гигантская диаграмма вместо уровней.

   В порыве полноты на одну схему выносят всё: 10–15 дорожек, десятки шагов, исключения. Схема перестаёт читаться, на презентации руководство теряет нить, и решения не принимаются. Это ровно тот случай «10 дорожек и 50 задач», который приводит SlideModel.

   Как избежать

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

5. Ошибка 5: передачи не подписаны и не проверены.

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

   Как избежать

   подписать каждую межполосную стрелку (что, в каком формате, каким каналом) и для каждой ответить на три вопроса: кто отправляет, кто принимает, как принимающий узнаёт, что пора действовать.

6. Ошибка 6: разрывы найдены, решений нет.

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

   Как избежать

   каждый разрыв до конца сессии получает организационное решение — владельца передачи, новый формат, автоматизацию или изменение порядка шагов — с ответственным и сроком. Через 4–6 недель проводится проверка по диаграмме «как должно быть».

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

План внедрения Swimlane Diagram

Диаграмма дорожек — лёгкая техника. Первый цикл укладывается в пять недель и не требует специального ПО.

1. Неделя 1: выбор процесса и границ. Выберите один межфункциональный процесс с историей сбоев: долгие сроки, жалобы клиентов, взаимные претензии отделов. Зафиксируйте, какое событие запускает процесс и каким результатом он заканчивается. Составьте список участников (отделы, роли, внешние стороны, системы) и выберите одно основание для дорожек. Найдите 2–3 реальных случая за последний месяц, по которым пойдёте на следующей неделе.

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

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

4. Неделя 4: диаграмма «как должно быть» и решения. Нарисуйте целевую версию: убрать лишние передачи, перенести решение в нужную дорожку, назначить владельца передачи. Для каждого отобранного разрыва сформулируйте организационное решение с ответственным и сроком. Где за передачей стоят несколько ролей, распишите их участие в RACI. Согласуйте решения с руководителями всех дорожек.

5. Неделя 5: запуск и первая проверка. Внедрите решения, обновите инструкции и шаблоны передач. Через 2–3 недели работы по новой схеме пройдите по ней один свежий реальный случай. Проверьте, исчезли ли отмеченные разрывы и не появились ли новые на соседних передачах. Перенесите диаграмму из стикеров в редактор с устойчивыми номерами шагов.

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

Как реализовать этот план с помощью фрейма «Swimlane-диаграмма» в OrgDevTools

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

Книги по теме Swimlane Diagram

• Гири Раммлер, Алан Брейч — «Improving Performance» (1990). Книга, в которой схемы получили название Swim Lane diagrams и стали инструментом анализа межфункциональных процессов. Отсюда в методике взгляд на процесс поверх оргструктуры и второе название — диаграмма Раммлера — Брейча. В части пересказов (например, у Lucidchart) книга ошибочно называется «Improving Processes».

• Ананд Джеярай, Вики Саутер — «Validation of Business Process Models Using Swimlane Diagrams» (2014), научная статья, не книга. Источник критического раздела: наглядность дорожек долго принималась на веру без эмпирической проверки.

• Стивен Алтер — «Service Responsibility Tables: A New Tool for Analyzing and Designing Systems» (2007), научная статья, не книга. Табличная альтернатива для распределения ответственности в сервисных процессах.