Парадокс избыточной вариативности.
В любой методике проектирование процессов есть тонкий момент - в любом разбираемом пример предполагается, что процесс линеен или ограниченно разветвляется на 3-5 сценариев. Исходя из этого предположения формируется большинство регламентов или bpmn схем, определяющих процессную модель компании.
Если сформировать журнал событий для любого процесса длинной более чем в пару часов и 5-7 шагов, то окажется что вариаций на порядки больше. Для процесса закупок "от заявки до поставки на склад" нормой является от 800 до 1200 вариантов прохождения. Правило Парето не работает - чтобы набрать 20% от общего числа случаев нужно выбрать от 40 до 60% всех сценариев. Ситуация повторяется во всех проектах, которые я делал, видел или слышал. Случаи низкой вариативности для процесса закупок, сбыта, работы с обращениями клиентов и других чаще являются признаком ошибки в формировании журнала событий.
Разбор всех сценариев с исполнителями физически невозможен, но если разобрать 50-60 из 800 оказывается, что все эти вариации обоснованы и не противоречат сути целевого процесса, пусть и не совпадают с ним по форме.
Причина такой ситуации в ограничениях, свойственных инструментам для формального описания процессов - попытка отобразить все нюансы прохождения процесса делает диаграмму нечитаемой для бизнес-пользователя. Создание подпроцессов не помогает - при большом уровне вложенности прикладной эксперт не видит, как отражены важные для него нюансы. Это ограничение ведет к трем сценариям
➤ Аналитик отрисовывает все возможные вариации, эксперт отказывает в верификации и на выходе получаем модель, не используемую на практике
➤ Аналитик упрощает модель - отказывает от описания сценариев прерывания процесса, циклов, даже если они оправданы, или укрупняет шаги - получается рабочий регламент или схема процесса для автоматизации, но она не отражает всех вариаций
➤ Инициатива по формализации процессов останавливается на высоком уровне, описываются зона ответственности, рисуются матрицы RACI, но сами процессы остаются "черными ящиками".
Это нормальная ситуация для применения технологии анализа хода процесса. Действуем поэтапно:
➤ Проводим анализ с целью улучшить определенные показатели процесса. Эти показатели завязаны на финансовые показатели компании, а не на соответствие регламенту
➤ Выделяем те варианты, для которых показатели ниже ожидаемого уровня и которые составляют значимую долю от общего числа случаев или же связаны с заметными финансовыми потерями
➤ В этих вариантах ищем "общие места" и корневые причины приводящие к нежелательной ситуации
➤ Разрабатываем варианты изменений, оцениваем соотношение эффекта к затратам и реализуем окупаемые изменения
Чаще всего в результате реализации изменений она упадет на 10-15%, но само по себе это не является достижением. Достижение это улучшение показателей процесса.
#holy_wars@hammered_screw
· 29.10.2025
кстати и очень странно Никто не возникает комментаторами под Вашими размышлениями...
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 29.10.2025
Скорее всего просто не интересно 🤷♂️ в компаниях поменьше надо сначала перейти к процессному подходу а потом уже все это. А в компании побольше не все хотят светиться в сети.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 29.10.2025
да и побольше часто живут на коленке Мне как-то немелкая аптечная сеть по договору отчет о продажах в экселях скидывала такой, что явно видно - делают руками люди. Я, конечно, написал его обработку. Не руками же проверять)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.11.2025
Спасибо. Можно подписаться на ТГ канал - там в статьях еще и ссылку друг на друга работают 😁 https://t.me/hammered_screw
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён