Тридцать пять значков вместо семи: как выбрать нотацию, которую будут читать

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

Сегодня в BPMN семь классов объектов, в каждом в среднем по пять экземпляров, — около тридцати пяти значков. Это почти алфавит. И бизнес-пользователи её читать перестали.

Показателен побочный факт: методологию в полном изложении невозможно разместить на одном слайде — минимальный формат, на котором она помещается, это А3.

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

Короткая карта нотаций

Нотация	Откуда	Для кого работает
SADT / IDEF	структурный анализ, семейство стандартов 1970–80-х	классика, с которой начинают; давно не развивается
UML	объектно-ориентированный анализ	разработчики; бизнес читает от силы пару типов диаграмм
ARIS	комплексное моделирование организации	аналитики; единственный вариант «вся компания целиком»
BPMN	нотация бизнес-процессов	была для всех, стала для специалистов
Диаграмма потоков (DFD)	1960–70-е, моделирование требований	все, кому нужны потоки и их преобразование
Блок-схема	ГОСТ, алгоритмы	все; читается со второго раза без обучения
Кросс-функциональная (дорожки)	развитие блок-схемы	все, где важно «кто что делает»

Пара комментариев к таблице, которые в неё не помещаются.

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

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

ARIS появился как визуальный интерфейс к настройке большой ERP-системы: предполагалось, что вы двигаете мышкой квадратики на схеме — и меняется бизнес-логика. Этого не произошло; попытка объединить две сложные системы даёт сложность, которая не складывается, а возводится в степень. Зато у ARIS осталось другое достоинство: это единственная методология, позволяющая смоделировать деятельность всей организации в комплексе — с любой степенью подробности и с любого количества точек зрения. Ценой соответствующей трудоёмкости.

Главный принцип: не будьте догматиком

История, которая объясняет отношение к значкам лучше любой теории.

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

Существенные характеристики при этом были у обоих одинаковые.

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

Диаграмма потоков: нулевой уровень и декомпозиция

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

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

Строится сверху вниз. Нулевой уровень (контекстная диаграмма) — вся система как один прямоугольник и её окружение.

flowchart LR
    Ж["Житель<br/>внешний объект"] -->|"заявка"| A["Выдача справки<br/>администрация"]
    Ж -->|"заявка"| БД[("База данных<br/>сайта")]
    БД -->|"запрос"| A
    A -->|"уведомление о статусе"| Ж
    A -->|"справка"| Ж

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

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

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

Пять ошибок, которые видно сразу

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

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

3. Стрелки без подписей. Если вы объявили содержание потока существенной характеристикой — а в диаграмме потоков оно существенно всегда, — подпись обязательна. И подпись должна быть предметом, а не действием: «бронирование» читается как действие, а поток называется «информация о доступном туре».

4. Двунаправленные стрелки. Их не бывает. Обмен документами — это две стрелки: одна к вам, вторая от вас.

5. Стрелки нулевого и первого уровня не совпадают. На нулевом стоит «поставка оборудования», а на первом вместо неё «монтаж и наладка». Так нельзя: либо элемент есть на обоих уровнях, либо его нет ни на одном. Это тот же принцип целостности — сумма декомпозиции равна целому.

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

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

Блок-схема, матрица ответственности и дорожки

Блок-схема — самая читаемая нотация, какая есть. Люди разбираются в ней со второго раза без обучения, всё остальное требует подготовки. Правила простые: модель всегда начинается знаком начала и заканчивается знаком окончания (иначе на многостраничных схемах непонятно, откуда стрелка); объекты располагаются сверху вниз и слева направо, змейкой; ветвление бывает бинарным (ромб «да/нет») и многовариантным (объект «альтернатива»), и на каждой стрелке ветвления нужно указывать условие перехода.

У блок-схемы один принципиальный недостаток: по ней непонятно, кто что делает.

Первым решением была матрица ответственности — таблица рядом со схемой: номер шага, ответственный исполнитель. Работает, пока шагов три-четыре. На схеме в десять страниц с циклическими ссылками матрица рядом только добавляет хаоса.

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

flowchart TB
    subgraph K["Контролёр"]
        A1["Измерить<br/>параметр"] --> A2["Занести<br/>в реестр"]
    end
    subgraph V["Владелец процесса"]
        B1["Сравнить<br/>с целевыми"] --> B2{"В допуске?"}
        B2 -->|"да"| B3{"Есть<br/>тенденция?"}
    end
    subgraph R["Руководитель процесса"]
        C1["Устранить<br/>отклонение"]
        C2["Устранить<br/>причину"]
    end
    A2 --> B1
    B2 -->|"нет"| C1
    C1 --> A1
    B3 -->|"да"| C2

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

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

Что выбрать

Сухой остаток получается коротким.

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

Вывод

Нотация — не предмет веры, а инструмент передачи смысла тем, кто по этой схеме работает.

Три вещи стоит унести. Читаемость важнее полноты: нотация из тридцати пяти значков точнее, чем из семи, но её не читают, а значит она не работает. Значок можно заменить, существенную характеристику — нет; легенда решает вопрос совместимости. И самые частые ошибки на схемах формальные: пропавшие деньги, безымянные стрелки, несовпадение уровней — их ловят за пять минут, а стоят они месяцев работы по неверной модели.

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

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