Чтобы упростить сложную блок-схему, отделите общий ход процесса от подробностей. Оставьте основные этапы и важные результаты на обзорной схеме, перенесите внутренние действия одного этапа в именованный подпроцесс и явно покажите его вход и точки возврата.
Не начинайте с уменьшения шрифта или удаления исключений. Схема может выглядеть аккуратнее, но стать менее полезной. Задача — дать читателю проследить основной путь, сохранив доступ к деталям, необходимым для работы.
Поймите, почему схему трудно читать
Прежде чем переставлять блоки, определите причину. На схеме могут смешиваться крупные этапы и отдельные нажатия кнопок, повторяться одинаковые проверки или располагаться все исключения на основном пути. В Boardmix можно редактировать обзорную и подробные блок-схемы рядом, сохраняя видимые связи между ними.
Подумайте, на какой вопрос должен ответить читатель:
- «Что происходит с моей заявкой?» — нужны основные этапы, ожидания и возможные завершения.
- «Что мне делать на этом этапе?» — нужны действия, решения, входные данные и передача работы.
- «Почему этот случай завершился неудачей?» — нужен соответствующий путь исключения и определяющие его сведения.
Попытка ответить на все три вопроса на одном визуальном уровне часто и создаёт путаницу. Несколько представлений могут описывать один процесс, не заставляя каждого читателя изучать все его шаги.
Если мешают только неаккуратные линии, сначала выровняйте фигуры и уменьшите количество пересечений. Короткий связный процесс не нужно делить на несколько схем ради внешней организованности. Выносите раздел отдельно, когда его детали отвлекают от общего пути, а сам раздел имеет понятный вход и результат.
Определите границы до выбора скрываемых деталей
В рекомендациях ASQ по построению блок-схем сначала определяются границы процесса, его начало, конец и нужная степень детализации. Примените этот принцип до перестановки блоков: запишите, что поступает на вход и что считается завершением.
В условном примере этой статьи границы таковы: от подачи сотрудником заявки на возмещение расходов до решения по ней и, в случае одобрения, передачи в финансовый отдел. Сама выплата находится за пределами схемы. Поэтому статус «Передана в финансовый отдел» не означает, что расходы возмещены.
В перегруженном оригинале могут быть открытие заявки, чтение чека, проверка обязательных сведений, запрос недостающего документа, изучение ответа, передача на согласование, фиксация решения, уведомление сотрудника и отправка одобренного пакета. Все эти действия полезны, но не все должны оставаться на обзорном уровне.
Сохраните исходную схему как опору при реорганизации. Сейчас меняется способ объяснения процесса, а не политика согласования расходов. Предложения изменить сам процесс должны находиться в отдельной, явно обозначенной версии.
Постройте обзорную схему с понятными результатами
Объедините действия примера в три этапа. Присвойте им постоянные идентификаторы, чтобы подробности можно было найти даже после перемещения фигур.
- P1 — Проверить документы. Установить, представлены ли необходимые подтверждающие сведения. Результаты — «Готова к рассмотрению» или «Отозвана». Заявка, ожидающая информации, остаётся внутри P1.
- P2 — Рассмотреть заявку. Уполномоченный сотрудник фиксирует одобрение или отказ. Отказ завершает процесс отклонённой заявкой, а не передачей в финансовый отдел.
- P3 — Передать одобренный пакет в финансовый отдел. Передать заявку и подтверждающие документы. Схема заканчивается этой передачей, а не выплатой.
Теперь основной путь выглядит так: Подана → P1 → P2 → P3 → Передана в финансовый отдел. На обзоре остаются два важных выхода: «Отозвана» из P1 и «Отклонена» из P2. Ни один не спрятан внутри общего блока «Завершена».
Не удаляйте результат только потому, что он встречается редко. Обзор должен сохранять исходы, которые меняют ожидания следующего участника. Небольшие внутренние проверки можно перенести в детали; различие между одобрением и отказом — нельзя.
Раскройте P1, сохранив его смысл
Над подробной схемой разместите короткое описание условий подпроцесса. Оно объясняет, какую работу тот должен выполнить:
- Вход: поданная заявка с идентификатором и приложенными документами.
- Цель: установить наличие требуемых подтверждающих сведений.
- Выходы: «Готова к рассмотрению» или «Отозвана».
- Состояние ожидания: «Ожидается информация». Это не успешное завершение.
Затем нарисуйте внутренний процесс:
- P1.1 — Изучить заявку и документы. Используйте перечень сведений, обязательных для этого типа заявки.
- P1.2 — Все необходимые документы представлены? Если да, присвойте заявке статус «Готова к рассмотрению» и передайте её в P2.
- P1.3 — Запросить недостающую информацию. Укажите конкретный документ или сведения, а не отправляйте необъяснимое «Отклонена».
- P1.4 — Дождаться ответа сотрудника. Исправленный пакет возвращается в P1.1. Явный отзыв заявки даёт результат «Отозвана». Без ответа сохраняется статус «Ожидается информация», пока действующий порядок сопровождения не предписывает иное.
Документы могут быть полными, но ещё не одобренными. P1 проверяет комплектность; P2 принимает решение по заявке. Объединение этих смыслов в блоке «Проверить» вернуло бы исходную неоднозначность.
Ожидание также отличается от цикла, который снова и снова отправляет один запрос. Это пауза до внешнего ответа. Если в организации действуют правила напоминания или закрытия заявки, покажите их реальные условия, а не придумывайте срок ради схемы.
Обеспечьте понятный переход между обзором и деталями
Назовите обзорный этап «P1 — Проверить документы», а подробную схему — «Детали P1». В обоих местах используйте одинаковые названия входа и выходов. Если обзор говорит «Готова к рассмотрению», а подробная схема возвращает «Одобрена», читатель не поймёт, одинаковы ли эти состояния.
Расположите детали рядом с родительским этапом на общей доске либо добавьте явную ссылку, если они находятся в другом документе. Соединитель с подписью «Детали P1» понятнее безымянной стрелки, исчезающей за краем страницы. По обозначению читатель должен найти продолжение без помощи автора.
Можно использовать символ предопределённого процесса, если он соответствует принятой нотации. Но подпись и связь важнее декоративной формы. Если организация использует формальную нотацию, например BPMN, следуйте её правилам подпроцессов, а не смешивайте обозначения произвольно.
Внутри подробного представления сохраняйте сопоставимый масштаб действий. «Рассмотреть заявку» и «Нажать значок вложения» не должны быть равноправными этапами, если только документ специально не описывает экранные операции. Инструкции по нажатиям лучше вынести в примечания или отдельное руководство.
Проведите три случая через оба представления
Выберите случаи, раскрывающие различия между уровнями. Это не новые действия процесса, а способ понять, сохранила ли реорганизация его смысл.
| Случай | Поведение в деталях | Что видно на обзоре |
|---|---|---|
| Все документы представлены; заявка одобрена | P1.1 и P1.2 возвращают «Готова к рассмотрению». | P1 → P2 → P3 → Передана в финансовый отдел. |
| Не хватает чека; сотрудник присылает его; заявка отклонена | P1.3 запрашивает чек. P1.4 получает его и возвращает пакет в P1.1. | P1 в итоге возвращает «Готова к рассмотрению». P2 возвращает «Отклонена»; P3 не начинается. |
| Сотрудник отзывает заявку, пока не хватает информации | P1.4 возвращает «Отозвана». | Процесс заканчивается отзывом, а не готовностью или одобрением. |
Во втором случае есть цикл внутри подробной схемы, но его не нужно тянуть через весь обзор. Родительская схема по-прежнему правдива: заявка остаётся на проверке документов, пока не будет готова или отозвана.
Если реальный случай не удаётся проследить, выясните, был ли шаг просто перенесён или случайно удалён. Сопоставьте оригинал, результаты родительской схемы и выходы подробной. Исправьте несоответствие до окончательного оформления.
Не заменяйте одну перегруженную схему множеством несвязанных
Разделение через каждые несколько блоков создаёт новую проблему: читатель тратит больше сил на поиск продолжения, чем на понимание процесса. Сохраняйте связный этап целиком. У подпроцесса должна быть причина для выделения: ясная ответственность, повторно используемая операция или существенная внутренняя логика решений.
Если одинаковая проверка встречается в нескольких местах, убедитесь, что она действительно одинакова. «Подтвердить личность перед изменением доступа» и «Убедиться, что в заявке есть идентификатор клиента» решают разные задачи. Похожего названия недостаточно для объединения.
В нашем примере разместите обзор наверху доски Boardmix, а детали P1 — прямо под ним. Перечень обязательных документов поставьте рядом с P1.2, где он используется, вместо того чтобы вмещать весь список в ромб решения. Различайте конечные состояния «Отклонена» и «Отозвана» и подписями, и оформлением; не полагайтесь только на цвет.
Откройте Boardmix, чтобы реорганизовать блок-схему. Начните с этапа, вызывающего больше всего вопросов, раскройте только его и не трогайте уже понятные разделы. Читатель должен суметь объяснить обзор, а затем найти точные инструкции для своего этапа.
