# Тридцать пять значков вместо семи: как выбрать нотацию, которую будут читать
> Разбор лекции по процессному управлению из программы MBA CIO: короткая карта нотаций — IDEF, UML, ARIS, BPMN, диаграмма потоков, блок-схема и дорожки; правило «не будьте догматиком»; правило чётности и пять типичных ошибок на диаграмме потоков.
Источник: https://blog.uspeshnyy.ru/blog/tridcat-pyat-znachkov/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2015-03-07
Теги: MBA, система, аналитика, инструменты, Процессное управление, Владислав Сирота
---
Когда появилась нотация BPMN, её главным преимуществом была простота: **семь значков**. Семь значков можно объяснить любому сотруднику, который должен читать схему процесса. Не рисовать — читать. Это примерно уровень первых трёх классов школы.
Сегодня в BPMN семь классов объектов, в каждом в среднем по пять экземпляров, — около **тридцати пяти значков**. Это почти алфавит. И бизнес-пользователи её читать перестали.
Показателен побочный факт: методологию в полном изложении невозможно разместить на одном слайде — минимальный формат, на котором она помещается, это А3.
Здесь и лежит главный критерий выбора нотации, который перевешивает все остальные: **схему должны читать те, кто по ней работает**. Разбираю карту нотаций и правила работы с ними — по девятой лекции [процессного управления](/blog/sutki-na-razgruzku/) из программы MBA CIO.
## Короткая карта нотаций
| Нотация | Откуда | Для кого работает |
|---|---|---|
| **SADT / IDEF** | структурный анализ, семейство стандартов 1970–80-х | классика, с которой начинают; давно не развивается |
| **UML** | объектно-ориентированный анализ | разработчики; бизнес читает от силы пару типов диаграмм |
| **ARIS** | комплексное моделирование организации | аналитики; единственный вариант «вся компания целиком» |
| **BPMN** | нотация бизнес-процессов | была для всех, стала для специалистов |
| **Диаграмма потоков (DFD)** | 1960–70-е, моделирование требований | все, кому нужны потоки и их преобразование |
| **Блок-схема** | ГОСТ, алгоритмы | все; читается со второго раза без обучения |
| **Кросс-функциональная (дорожки)** | развитие блок-схемы | все, где важно «кто что делает» |
Пара комментариев к таблице, которые в неё не помещаются.
**IDEF** задумывался масштабно: под семейство стандартов зарезервировали семнадцать номеров. Денег хватило не на всё, и сегодня тема существует как хорошая классика — с неё начинают, но её не развивают.
**UML** упирается в словарь. Попробуйте объяснить менеджеру по персоналу, что существует класс «человек», у которого есть экземпляр «сотрудник» со свойствами и методами, позволяющими развивать его собственные свойства. На этом месте менеджер по персоналу желает вам хорошего дня. В компаниях-разработчиках тема живёт и по сей день, за пределами — почти нет.
**ARIS** появился как визуальный интерфейс к настройке большой ERP-системы: предполагалось, что вы двигаете мышкой квадратики на схеме — и меняется бизнес-логика. Этого не произошло; попытка объединить две сложные системы даёт сложность, которая не складывается, а возводится в степень. Зато у ARIS осталось другое достоинство: **это единственная методология, позволяющая смоделировать деятельность всей организации в комплексе** — с любой степенью подробности и с любого количества точек зрения. Ценой соответствующей трудоёмкости.
## Главный принцип: не будьте догматиком
История, которая объясняет отношение к значкам лучше любой теории.
Диаграмму потоков разрабатывали параллельно две пары авторов, ничего не знавшие друг о друге. Получилось два варианта одной и той же нотации. Отличались они… начертанием: у одних внешний объект рисовался прямоугольником с тенью, у других — просто прямоугольником. Хранилище у одних выглядело как лежащий на боку стакан в разрезе, у других — как труба.
Существенные характеристики при этом были у обоих одинаковые.
Вывод, который стоит из этого сделать: **значок вторичен, характеристика первична**. Не нашли в редакторе прямоугольник с тенью — рисуйте треугольник, ромб или звёздочку. Не нашли стакан в разрезе — рисуйте стоящую банку. Единственное обязательное условие: **снабдите модель легендой** и не меняйте сами существенные характеристики. Вот их менять нельзя.
## Диаграмма потоков: нулевой уровень и декомпозиция
Самая полезная нотация для того, кто разбирается со своим процессом впервые. Она показывает, как каждый элемент деятельности преобразует входные потоки в выходные, — не различая при этом процесс, проект и функцию.
Что она отражает: информационные, материальные и управляющие потоки, их хранилища, а также источники и адресатов — внешние и внутренние.
Строится сверху вниз. **Нулевой уровень (контекстная диаграмма)** — вся система как один прямоугольник и её окружение.
Дальше **первый уровень** — та же система, раскрытая внутрь. Порядок сборки такой, и его стоит соблюдать:
1. рисуем **входящие** потоки — те же самые, что вошли на нулевом уровне;
2. рисуем **исходящие** — те же самые, что вышли на нулевом;
3. спрашиваем: **кто обрабатывает входящие**? В примере — служба одного окна;
4. спрашиваем: **кто порождает исходящие**? Курьеры доставляют справку, служба одного окна уведомляет о статусе;
5. достраиваем середину: кто-то ведь справку готовит — значит, появляются специалисты, а между ними и курьерами — хранилище нарядов-заказов.
Декомпозиция продолжается до уровня, на котором она перестаёт быть нужной.
## Пять ошибок, которые видно сразу
**1. Компания работает бесплатно.** Самая частая и самая смешная: на схеме есть заявка, есть подтверждение, есть путёвка — и нигде нет денег. Проверяйте первым делом, платит ли клиент на вашей схеме.
**2. Не сходится правило чётности.** Огрублённо: сколько стрелок вошло, столько должно и выйти. Это не жёсткий закон — бывают обоснованные случаи, когда на пять входящих один исходящий. Но каждый раз, когда счёт не сошёлся, задайте вопрос «почему». Обычно ответ такой: **какое-то действие совершено без реакции**. Вы отправили клиенту подтверждение и путёвку, а он вам в ответ — ничего.
**3. Стрелки без подписей.** Если вы объявили содержание потока существенной характеристикой — а в диаграмме потоков оно существенно всегда, — подпись обязательна. И подпись должна быть **предметом, а не действием**: «бронирование» читается как действие, а поток называется «информация о доступном туре».
**4. Двунаправленные стрелки.** Их не бывает. Обмен документами — это две стрелки: одна к вам, вторая от вас.
**5. Стрелки нулевого и первого уровня не совпадают.** На нулевом стоит «поставка оборудования», а на первом вместо неё «монтаж и наладка». Так нельзя: либо элемент есть на обоих уровнях, либо его нет ни на одном. Это тот же принцип целостности — **сумма декомпозиции равна целому**.
**Про типы линий.** Информационный поток — сплошная стрелка, материальный и ресурсный — штрихпунктир, управляющий — пунктир. Если предмет потока для вашей задачи не важен, можно использовать одинаковые стрелки: главное — решить это сознательно и записать в легенду.
**Где сегодня помогает AI.** Разбор чужих схем перестал быть ручной работой: модель проверяет диаграмму на формальные ошибки — безымянные стрелки, несовпадение уровней, нарушенное правило чётности, отсутствующий денежный поток — и возвращает список мест, куда смотреть. Содержательные ошибки остаются человеку, но формальных на схемах обычно больше.
## Блок-схема, матрица ответственности и дорожки
**Блок-схема** — самая читаемая нотация, какая есть. Люди разбираются в ней со второго раза без обучения, всё остальное требует подготовки. Правила простые: модель всегда начинается знаком начала и заканчивается знаком окончания (иначе на многостраничных схемах непонятно, откуда стрелка); объекты располагаются сверху вниз и слева направо, змейкой; ветвление бывает бинарным (ромб «да/нет») и многовариантным (объект «альтернатива»), и на каждой стрелке ветвления нужно указывать условие перехода.
У блок-схемы один принципиальный недостаток: **по ней непонятно, кто что делает**.
Первым решением была **матрица ответственности** — таблица рядом со схемой: номер шага, ответственный исполнитель. Работает, пока шагов три-четыре. На схеме в десять страниц с циклическими ссылками матрица рядом только добавляет хаоса.
Отсюда выросла **кросс-функциональная диаграмма** — она же диаграмма дорожек, она же диаграмма бассейнов. Объекты те же, что в блок-схеме, но модель строится дорожками: на каждой располагаются действия, которые выполняет тот, кто по этой дорожке «плывёт».
По дорожкам могут плавать роли, должности, конкретные люди, подразделения, организации — а одну из дорожек удобно отдать информационной системе, которая процесс автоматизирует, и ещё одну клиенту. Для постановки задачи разработчикам это, пожалуй, самый удобный формат: сразу видно, что одно подразделение передаёт другому и что при этом уходит в систему.
**Одна тонкость.** В идеале не должно быть задач, которые выполняются несколькими исполнителями: если работу можно разделить — разделите. Но есть работы, где разделить нельзя: два человека несут бревно. Если их дорожки соседние, задача просто рисуется на границе. Если не соседние — рисуется **дважды, с одинаковым названием**, в обеих дорожках.
## Что выбрать
Сухой остаток получается коротким.
- Нужно внедрить процессный подход в масштабах всей компании, связать между собой процессы, функции, данные и системы — **ARIS**, альтернатив пока нет, но приготовьтесь к трудоёмкости.
- Нужно быстро разобраться с одним процессом в отрыве от остального — **диаграмма потоков плюс блок-схема плюс дорожки**. Полный комплекс здесь не нужен.
- Нужно, чтобы схему читали исполнители, — берите ту нотацию, где меньше значков, и снабжайте её легендой.
## Вывод
Нотация — не предмет веры, а инструмент передачи смысла тем, кто по этой схеме работает.
Три вещи стоит унести. **Читаемость важнее полноты**: нотация из тридцати пяти значков точнее, чем из семи, но её не читают, а значит она не работает. **Значок можно заменить, существенную характеристику — нет**; легенда решает вопрос совместимости. И **самые частые ошибки на схемах формальные**: пропавшие деньги, безымянные стрелки, несовпадение уровней — их ловят за пять минут, а стоят они месяцев работы по неверной модели.
**Следующий шаг:** нарисуйте нулевой уровень своего процесса — систему одним прямоугольником, вокруг внешних участников, между ними подписанные стрелки. Потом посчитайте стрелки между собой и клиентом. Если их количество не сходится или на схеме нет денег, вы уже нашли первое место, где ваше представление о процессе расходится с тем, как он устроен.
Заключительный разбор серии — [где на самом деле проходят границы между под-процессами](/blog/dogovor-podpisan-i-do-svidaniya/) и почему схема разваливается на стыке продажи и доставки.