Короткий ответ — потому что чаще всего их невозможно читать.
Длинный — очень часто схема процесса написанная в любой нотации довольно нечитаема, даже короткая, на ней много запутанных мест, много разных шрифтов, непонятно что значат все эти разноцветные прямоугольнички, ромбики и кружочки. Поэтому основные потребители отказываются читать или читают с неохотой и большими временными затратами, ругаются и не хотят больше видеть никаких схем. Аналитик считает, что время было потрачено зря, лучше бы над описанием требований ещё раз поработал, но если стремиться упростить читателю жизнь, то блок‑схема процесса может очень сильно увеличивать качество проработки требований и время потраченное на её описание окупится сполна. В случае с регламентами я лично считаю схему бизнес‑процессов их неотъемлемой частью, т.к. хорошо оформленная схема ускоряет процесс написания регламента, увеличивает его исполняемость и сокращает время на поиск нужной информации в разных ситуациях.
За свою рабочую корпоративную жизнь я создала много регламентов и автоматизировала много процессов и блок‑схема является моим любимым инструментом для работы. И вообще считаю что если есть возможность что‑то нарисовать, а не описать словами, рисуй, (ещё в третьем классе учительница мне дала такой совет — не знаешь как решить задачу — рисуй), ну и за время использования выявила для себя несколько правил увеличивающих читаемость схемы:
Должно быть чётко видно где начало и конец процесса, только одно начальное событие и максимум два конечных (успех/неуспех), особенно для схем, в которых больше 10 элементов. Каждое событие в процессе должно быть подписано и должно быть ясно, что это за событие — «Запуск конвейера», «Нажатие на красную кнопку», «Наступило 15:00» и т. д.
Процесс должен двигаться последовательно — сверху вниз справа налево неважно горизонтальная или вертикальная схема. Это пишут в каждой статье на эту тему, но никто не осознает важность этого правила — мозг привык читать слева направо и сверху вниз, если нужно переключать внимание на это, сопротивление возрастает и желание вникнуть у заказчика просто отмирает. Если мы рисуем кроссфункциональную схему, может быть такое что процесс по стрелкам визуально возвращается вверх или влево, но должно быть соблюдено второе правило — если вверх, то вправо, если влево то вниз. Может быть исключением очень маленькая схема не более чем на 7–8 элементов. Выравнивание блоков относительно друг друга — по центру вертикально и горизонтально. Это придаёт аккуратный вид и проще считывается.
В одной схеме должно быть не более 30 элементов включая развилки и блоки событий, если больше, значит можно выделить из них подпроцессы, которые можно описать на отдельных схемах, скорее всего так будет удобнее и фокус внимания не соскользнёт с основного процесса. Идеально, если схему можно распечатать на А4 и читать её без лупы. Монструозные процессы на очень много элементов тоже существуют, но по моему опыту их довольно легко разбить на смысловые части и описывать по отдельности. Если же это все‑таки сложно (такое часто бывает на схемах процесса as is), например в схеме на 84 элемента с 60-го нужно вернуться на 10-й шаг, то это как раз говорит о том, что процесс требует оптимизации.
Стрелки перехода не должны пересекаться и желательно должны быть вообще прямыми или с одним‑двумя углами, чем меньше пересечений и виляний по листу, тем меньше усилий нужно приложить мозгу, чтобы не забыть откуда мы вообще пришли. Для кроссфункциональных схем это особенно актуально, т.к. границы дорожек тоже могут вносить свою путаницу. Если из одного элемента выходит несколько стрелок, они должны быть подписаны. Стрелки не должны уходить в никуда и возникать из ниоткуда, т. е. каждая переходит в какой‑то элемент. Это кстати моё любимое правило, потому что если при рисовании схемы стрелки превращаются в лапшу, значит ты или придумал какую‑то фигню, или она происходит в реальности и в момент, когда ты пытаешься распутать стрелки, приходит озарение как реально оптимизировать это место.
Каждое «путешествие» по процессу должно приходить в конечное событие, очень частая ошибка, что в действие приходит стрелка, но не выходит и блок действия повисает в воздухе, что дальше непонятно.
Текст в блоке действия должен начинаться с глагола совершенного вида (отвечает на вопрос что Сделать?) — «нажать кнопку», «поставить подпись», «открыть окно», «переслать файл», «отправить json в брокер», «обработать хвост поросёнка зелёнкой» и т. п., и описывать одно конкретное действие. Как следствие текста в блоке не должно быть много, и по хорошему читающий должен понять сразу, о чем блок, если не удаётся уместить в 6–8 слов, значит с большой вероятностью тут что‑то такое зарылось, что надо отрыть и переделать в процессе скорее всего, либо это подпроцесс, который нужно описывать отдельно.
Оформление — не должно быть большого шрифтового и цветового разнообразия, максимально стандартные и строгие шрифты — Arial, Calibri, Segoe, Verdana, два‑три цвета пастельных оттенков, чёрный или яркий фон выглядит круто, но для осмысленного чтения документации довольно плохо. Оформление элементов, стрелок, подпроцессов должно быть одинаковым и описано в легенде.
Необязательно, но часто бывает полезно при описании каких‑то реальных производственных или кроссфункциональных процессов, нумеровать блоки по порядку и делать к ним полное описание. Это больше актуально для регламентов. Часто такие процессы включают в себя кучу мелких действий одним сотрудником типа «оформить заявку, распечатать ее, поставить печать, расписаться, сложить в синюю папку» — такое действие излишне разбивать на несколько блоков, т.к. это делается все последовательно и одним человеком, но в таких блоках могут скрываться важные нюансы, которые заказчик хочет видеть на схеме, но их описание занимает много места и ухудшает читаемость.
Самое сложное — не стоит пытаться на одну схему уместить несколько смыслов — процесс среди людей и процесс внутри системы, процесс продажи и процесс закупки, процесс оплаты и процесс возврата, и т. д.. В самом начале описания нужно определиться что мы описываем и цель, которую преследуем этим описанием. Процессы автоматизации реальных действий лучше всего разбивать на две смысловые части и описывать их отдельно друг от друга, т.к. скорее всего пользователю вообще неясно зачем смотреть какие подводные процессы происходят за экраном системы, а программисту все равно кто куда папки с документами носит.
Не нужно плодить сущности — например если по ходу процесса у пользователя есть выбор из двух вариантов, который ничего не меняет, то не надо делать блок выбора, два действия и направлять их результат в один следующий, это можно описать одним блоком действия. Если есть необходимость описать этот выбор и какие‑то возможные критерии, нужно сделать отдельное описание этого блока или схемой или текстом. Но при этом нельзя пропускать какие‑то смысловые элементы, даже если они кажутся очевидными.
Разберём примеры
Первый пример. Процесс покупки абонемента через бот в Telegram.
4 стартовых события, подписано только одно, что вероятно и является реальным началом процесса, остальные добавляют только визуальный шум. 4 события окончания, ни одно из них не подписано, чем и когда заканчивается процесс непонятно, по смыслу можно оставить два — абонемент куплен и абонемент не куплен и все стрелки сводить к ним.
Более менее соблюдено правило, но все равно в некоторых местах мозг спотыкается, но скорее по смыслу, это обсудим дальше.
Количество элементов небольшое, это отлично.
В самом начале процесса в регионе подтверждения регистрации и отображения меню есть некоторая квантовая запутанность, много стрелок, они друг с другом пересекаются в нескольких местах, выглядит так, как будто последовательные процессы попытались нарисовать параллельно.
Все приходит к концу, это отлично!
По тексту тоже все гладко.
Оформление тоже не даёт глазам разбежаться
Тут довольно немного элементов, но есть места где можно было бы описать поподробнее в отдельной табличке, я бы описала отдельно про выбор абонементов, например.
Смысл процесса однозначен, что конечно упрощает чтение.
В самом начале процесса есть некоторая запутанность, как я уже отмечала, поэтому мозг спотыкается и непонятна последовательность действий, как будто не хватает блоков с регистрацией у пользователя, либо подпроцесса регистрации и авторизации. Я никогда не участвовала в проектах с авторизацией, но насколько я знаю, на этом целый отдельный аналитик часто сидит, в трёх блоках тут так быстро не нарисуешь, тут либо слишком мало описания, либо наоборот слишком много и нужно выделять подпроцессы. В дорожке с пользователем есть место выбора варианта оплаты, но вне зависимости от выбора пользователя процесс не меняется, он как шёл к подтверждению оплаты, так и идёт, можно было вместо трёх элементов оставить один. Но и все равно оплата это сложный процесс, его тоже нужно бы описать отдельно.
Из текущих сведений о процессе, я бы поправила его к такому виду, хотя у меня остаётся всё ещё много вопросов — это как раз хорошая база для дальнейшей проработки.
Второй пример. Процесс управления записями через бот в Telegram.
По непосредственному оформлению вопросов не так уж много — много лишних событий и все без названия, блок «Запись существует» должен быть шлюзом, а не действием, когда поменяем, изменится и процесс, ну и некоторые стрелки просятся быть подписанными.
Есть вопросы по смысловой части процесса — почему мы проверяем существование записи после того, как хотим её отменить, почему действия пользователя идут последовательно, хотя они зависят от действий бота, пока бот не покажет, пользователь не может ничего выбрать, раз уж он тут тоже главный, нужно его ждать, даже если это наносекунды, но самое основное — кажется это попытка и записи и подтверждение этой записи одновременно. Это последовательные действия, в целом они могут быть описаны на одной схеме через промежуточное событие запроса подтверждения, но в текущем варианте есть некоторая запутанность и в целом от описания остаётся ощущение недосказанности. И так как есть непонятки с основным посылом блок-схемы, я даже не могу привести пример её исправления, т.к. нужно разделять смыслы, а после разделения смыслов новая схема со старой ничего общего иметь не будет.
Вместо послесловия
Многие из этих правил соблюсти очень легко, но занудно, некоторые требуют некоторого умственного напряжения, но зато и сделать это интересно. Легко читаемая и аккуратная схема обладает небольшим свойством — по ней очень легко задавать вопросы и находить узкие места, чем обычно и занимаются заказчики и программисты, это конечно несколько бьёт по самолюбию человека, который усердно её клепал, но даёт мощный толчок к развитию.