Это первая из двух частей. В этой статье расскажу про задачу с Кайдзен-офисом в девелоперской компании, про то, почему обычные методы оптимизации не работают для процессов с очередями, и про то, что такое DES. Если интересна более углубленная практика - в следующей части опубликую подробный разбор реального кейса автосервиса с цифрами AS-IS и TO-BE.
Вступление
В конце 2025 года в нашей региональной девелоперской компании мы запустили Кайдзен-офис.
Это такой формат, когда любой сотрудник может предложить идею, как улучшить работу. От «давайте перестанем дублировать отчёты в Excel и Power BI» до «давайте перестроим маршрут согласования заявок». Уже за сам факт того, что сотрудник озвучил потенциально полезную идею (то есть экспертная группа её положительно оценила), мы платим небольшое, но приятное денежное вознаграждение. А уж если идея доходит до внедрения и начинает приносить измеримый эффект, цифры уже другого, ещё более приятного порядка.
По моему мнению, Кайдзен сам по себе — просто потрясающая вещь для развития кадров, вовлечения сотрудников в процессное управление и тому подобное. Но это не основная тема данной истории. Эта история о том, как оценить все эти идеи не субъективно, а по-настоящему. Что действительно является оптимизацией, которая принесёт компании деньги, а что — просто галлюцинация, с которой согласились эксперты.
К моменту запуска Кайдзен-офиса компания за пару лет выросла с 50 до 300+ человек. Это девелопер, который занимается региональной экспансией: новые объекты, новые регионы, новые команды от месяца к месяцу. Процессы выстраивались на ходу и при этом обязаны были масштабироваться. Что-то закреплялось в регламентах, что-то существовало в режиме «у нас принято так». Процессный офис — это я и трое моих коллег-аналитиков.
Идеи пошли на удивление быстро, по 10-15 в месяц. Часть из них вообще не про процессы: «нужно меньше совещаний», «давайте сделаем меньше урн для мусора в офисах». Часть про автоматизацию: «эту задачу можно полностью забрать в RPA». А часть, как мы и хотели, про реальную перестройку процессов: маршруты согласования, разделение зон ответственности, временные окна обработки заявок.
И вот с этой третьей, самой близкой процессному офису категорией появились вопросики.
Приведу простейший на первый взгляд пример. Один из коллег предложил перестроить процесс согласования заявок на расходование (ЗНР). Заявка на расходование — это, упрощённо, документ, по которому подрядчик получает деньги за выполненные работы. Задержка с согласованием бьёт по подрядчику, портит отношения и в перспективе влияет на сроки строительства. Согласование идёт через нескольких исполнителей: финансисты, экономисты, менеджеры ТМЦ, бухгалтерия, профильный руководитель. У всех своя загрузка, свои сроки, свои часовые пояса. Буквально от Москвы до Дальнего Востока, разные проекты, разный поток заявок в разных регионах (который, кстати, легко можно отследить по реальным данным из 1С).
Идея была конкретная и заманчивая: ввести фиксированные временные окна для согласования. У такого-то исполнителя с 10:00 до 12:00, у другого с 14:00 до 16:00. Цель — синхронизировать работу согласующих, убрать хаотичные «забегания» на проверку заявок между другими задачами или тенденцию «отложить всё на последний момент, пока не настанет крайний срок».
Звучит разумно. Но когда я начал думать, как идею должна понять и оценить экспертная группа, я застрял.
Ускорит ли это согласование в целом, или замедлит? Если исполнитель согласует только в своё окно, заявки будут копиться в очереди и ждать слота. Возможно, в среднем стало быстрее: согласующий концентрируется на задаче, а не дёргается между десятью контекстами. А возможно, медленнее, потому что заявка, пришедшая в 12:01, ждёт следующего дня.
Как изменится загрузка исполнителей? Окно может перегрузить человека в этот двухчасовой слот настолько, что качество согласования упадёт. А может, наоборот, разгрузить, потому что нет постоянных переключений между задачами.
Что произойдёт с регионами, где поток заявок неравномерный? На одних проектах 30 ЗНР в неделю, на других 3. Одно и то же окно для всех — оптимально ли это? И какие именно окна согласования действительно самые оптимальные для синхронизации процесса?
И главное: как просчитать это до внедрения, не запуская пилот?
Заслужил ли инициатор идеи первое вознаграждение? Когда мы соберём экспертную комиссию для оценки (а это уважаемые люди от бизнеса — руководители тех же финансистов, экономистов и девелоперов), они точно спросят нас, как специалистов по процессам: как внедрение должно повлиять на скорость процесса? на загрузку ресурсов? И мы как специалисты должны ответить на эти вопросы. Но как?
Можно провести пилот. Но проводить пилоты, чтобы оценить каждую подобную идею — ресурсов и времени не хватит. У меня три аналитика. У нас десятки текущих задач. Запустить пилот на месяц, наблюдать, собирать данные, потом ещё месяц анализировать — этого мы не могли себе позволить ради оценки одной идеи.
Нарисовать схему AS-IS и схему TO-BE — первое, что приходит на ум бизнес-аналитику, и это было сделано очень быстро. Но как вы понимаете, на вопросы выше она нам никак не ответила. Схема не показывает нам, «что будет, если мы это внедрим», если речь не идёт про классическое устранение потерь (ненужных или дублирующихся операций, лишних циклов и тому подобное).
Следующий шаг — попытка оцифровать всё в Excel. Такую «модель» я тоже пытался построить, но тут оказалось: слишком много переменных, слишком много взаимных влияний, слишком много стохастики (поток заявок неравномерный, длительность согласования у разных людей разная).
Мне нужен был инструмент, который умеет просчитывать гипотезу до её внедрения. Смоделировать различные сценарии, где «модель» — это не схема процесса, а нечто большее, описывающее, как этот процесс работает с учётом ресурсов (людей), их графиков работы, их загрузки, с учётом статистики по потоку заявок и вероятностей движения заявок по различным веткам процесса. Не визуально описать, а именно посчитать. И для такого простейшего процесса (если говорить про его BPMN-схему) задача стала выглядеть очень и очень нетривиальной.
И тут совершенно случайно сошлось два события: я столкнулся с этой задачей, начал искать существующие в доступе инструменты для симуляции процессов, и одновременно с этим одна из компаний-разработчиков ПО для моделирования бизнес-процессов в BPMN анонсировала выпуск именно такого инструмента (о чудо!) встроенного именно в ту самую платформу, в которой мы уже моделировали процессы. И для работы в той нотации, в которой мы уже описываем и обсуждаем все наши взаимодействия в компании (BPMN 2.0).
Для разогрева данной тематики ребята из этой компании объявили проведение чемпионата по дискретно-событийному моделированию (DES). Я подал заявку без расчёта на призовое место, но чтобы протестировать инструмент на более сложной задаче и понять, подойдёт ли он мне для оценки Кайдзен-заявок.
Через два месяца я занял второе место из 120 участников, набрав 271 балл из 300. И главное — вышел из чемпионата с твёрдым пониманием, что половина моих интуитивных гипотез по оптимизации процессов всю мою карьеру была, мягко говоря, неоптимальной.
Эта статья — про то, как погружение в имитационное моделирование изменило мои представления об оптимизации бизнес-процессов и о бизнес-анализе в целом.
Почему обычные методы не работают
Прежде чем перейти к разбору, давайте честно посмотрим на инструменты, которыми обычно оценивают такие идеи. Их три с половиной.
AS-IS / TO-BE схемы
Это первое, к чему тянется рука процессного аналитика. Нарисовать процесс «как есть», нарисовать процесс «как будет», показать разницу. На BPMN-схеме все видят: вот тут был лишний шаг, мы его убрали. Красота!
Проблема в том, что схема не считает. Схема — это карта. Карта показывает, где дорога, но не показывает, сколько машин на ней стоят в пробке в восемь утра. Если вы убрали один шаг из процесса, схема покажет, что процесс короче. Но она не скажет:
стало ли быстрее в реальности?
что произошло с очередями к ресурсам, которые этот шаг разгружали?
не превратилась ли «оптимизация» в перегрузку другого участка процесса?
В моём кейсе с ЗНР AS-IS и TO-BE схемы выглядели бы примерно одинаково: те же согласующие, те же связи, разве что добавились бы события-таймеры или другие длительности выполнения задач с новыми временными окнами. Это нулевая ценность для принятия решения.
Excel
Второй инструмент, к которому тянется рука любого менеджера и аналитика - табличка в Excel. Загрузим статистику, посчитаем средние, прикинем эффект.
Excel прекрасен, но не работает с очередями.
Точнее, работает — если ваш процесс это последовательность независимых операций с детерминированной длительностью. Заявка пришла → 30 минут на согласование → ушла. Если вы такое встречали в жизни, поделитесь, пожалуйста, контактом вашего работодателя.
Реальный процесс работает иначе, по крайней мере пока мы имеем дело с людьми, а не с роботами. Заявки приходят не равномерно, а пуассоновским потоком (упрощая: случайно, с периодическими пиками). Длительность согласования тоже варьируется — в зависимости от сложности заявки и доступности согласующего. Один согласующий может быть в отпуске, другой в командировке, третий обрабатывает одновременно ЗНР, договор и совещание в Teams.
Когда я попытался построить Excel-модель для задачи с ЗНР, я получил таблицу на 47 строк, в которой каждая строка зависела от 5-6 параметров, причём часть параметров была случайными величинами. Чтобы это решить в Excel, надо было либо упростить модель до бесполезного состояния, либо лезть в Monte Carlo через VBA или Python.
Экспертная оценка («у меня же опыт»)
Третий метод — собрать экспертов в переговорке и спросить, что они думают. Этот метод хорош тем, что бесплатный. И тем, что он работает, но только в 30% случаев. Остальные 70% - это та самая ситуация, когда «казалось логичным, внедрили, стало хуже». В нашем же случае экспертная группа с «у вас же опытом» логичным образом вернула бы все эти вопросы «ты же аналитикам».
Я уверен, у вас в карьере были такие случаи. Их все стесняются. На своём опыте могу честно признаться: я внедрял оптимизации, которые казались очевидными, и потом обнаруживал, что эффект либо нулевой, либо отрицательный. Не потому что я какой-то не такой аналитик. А потому что человек в принципе плохо предсказывает поведение систем с очередями и стохастикой. Это известный когнитивный баг.
В литературе подобные эффекты обсуждают, например, через парадокс Браесса: если в дорожной сети добавить новый удобный участок, средняя скорость потока может упасть, а не вырасти. Потому что водители, не координируясь, выбирают локально оптимальный маршрут, который коллективно создаёт затор. То же самое происходит в бизнес-процессах: локально логичное решение может ухудшить систему в целом.
Бенчмарки и «у конкурентов так»
Это полу-метод. Полу — потому что он работает только если у конкурентов вы видите не результат, а причину результата, а это почти никогда не так.
«У соседнего автосервиса меньше очереди, потому что они выдают авто после 18:00». Возможно. А возможно — потому что у них другой состав мастеров, другая структура заявок, другая стоимость работ. Перенести их решение к себе и ожидать тот же эффект — это карго-культ.
Что нужно вместо
Нужен инструмент, который позволяет:
Описать систему как набор процессов, ресурсов, потоков, вероятностей и времени.
Прокрутить работу этой системы за реалистичный период (день, месяц, год).
Получить на выходе не «среднее значение», а распределение результатов: что будет в худшем случае, что в лучшем, что в типичном.
Повторить с другими параметрами и сравнить варианты.
Это и есть имитационное моделирование. И конкретно для бизнес-процессов — дискретно-событийная симуляция, DES (Discrete-Event Simulation).
Что такое DES, на пальцах
Дискретно-событийная симуляция (Discrete-Event Simulation, далее просто DES) — это способ заставить компьютер прокрутить работу вашего бизнеса от начала до конца, на любом отрезке времени, с учётом всех ваших ресурсов, всех вероятностей, всех очередей и всех простоев.
Представьте, что ваш бизнес — это театральная пьеса. Есть актёры (люди), есть реквизит (оборудование, помещения), есть сценарий (процессы), есть зрители (клиенты). И есть время. Пьеса начинается утром в понедельник, заканчивается через месяц.
Обычно вы видите только премьеру: то, как пьеса прошла в реальности. Один раз. С теми зрителями, которые пришли. С теми актёрами, которые сегодня в форме. Получили выручку, посчитали маржу, обсудили что было не так на планёрке. Если хотите проверить, что будет, если поменять состав актёров или добавить ещё один акт, то играете пьесу заново, в реальности, на живых клиентах. Это и есть пилот. Долго, дорого, рискованно.
DES — это репетиция, на которой вместо реальных актёров и зрителей математические модели, описывающие их поведение. Компьютер прокручивает пьесу не один раз, а тысячи. С разными случайными вводными: один раз пришло много клиентов в обед, другой раз заболел диагност, третий раз поломалась машина у поставщика запчастей. Каждый прогон даёт свой результат. Из тысяч прогонов вы получаете не одно число, а распределение: «в типичном месяце прибыль 4.5 млн, в худшем 2.1, в лучшем 6.8».
Что нужно описать в DES-модели:
Сущности (заявки), которые движутся через систему. В нашем кейсе с ЗНР — это сами ЗНР. В автосервисе — обращения клиентов по ремонтам автомобилей. В банке — тоже обращения клиентов (и они могут быть самыми разными, и каждое — требует отдельной проработки). В больнице — обращения пациентов. Все эти заявки появляются, обрабатываются, уходят с разным результатом. Некоторые уходят даже не дождавшись своей очереди.
Поток заявок. Когда они приходят и с какой плотностью. Обычно описывается распределением (часто Пуассоновским, если заявки приходят независимо и случайно).
Ресурсы, которые обрабатывают заявки. Люди, оборудование, помещения. У каждого ресурса свой график работы, своя ставка в деньгах, своя производительность.
Процесс — последовательность задач, через которые проходит сущность. С "разветвлениями" (XOR-шлюзы: 70% заявок идут так, 30% иначе), параллельными ветками, циклами (например, переделка).
Длительности задач — обычно тоже распределения, не одно число. Диагностика может занять от 15 до 45 минут, и обычно это не равномерно: чаще всего около 25, реже короче, реже длиннее.
Финансовая часть — доходы, прямые расходы, накладные. Чтобы на выходе получать не только время и очереди, но и P&L.
Дальше компьютер берёт всё это и проигрывает. На каждой из тысяч итераций, с учётом заданных параметров и распределений, решает: что сейчас происходит, кто свободен, кто занят, куда идёт следующая заявка, сколько денег заработали или потратили на данном шаге. И так час за часом, день за днём, по выбранному вами горизонту симуляции, но эти «часы» и «дни» компьютером просчитываются за миллисекунды. Так вы можете имитировать работу вашего процесса хоть на 10, хоть на 100 лет вперёд (если это входит в ваши планы).
Зачем это всё (короткая теория)
Почему же DES даёт принципиально другой результат, чем Excel или BPMN-схема?
Любой бизнес-процесс с потоком это система массового обслуживания. Раздел теории вероятностей, который возник из практических задач телефонии в начале XX века. В 1909 году датский математик Агнер Эрланг, работавший в Копенгагенской телефонной компании, опубликовал работу, в которой математически описал поведение телефонных коммутаторов: как зависит количество потерянных вызовов от количества линий и интенсивности входящего потока. Из этой работы выросла вся современная теория очередей.
Главное, что показал Эрланг и его последователи: поведение системы с очередями не линейно. Если у вас сейчас загрузка ресурса 70%, и вы добавите ещё 10% потока, очередь не вырастет на 10%. Она вырастет нелинейно, иногда в разы. А если загрузка перевалит за 85-90%, система становится крайне чувствительной к малейшим колебаниям. Очередь начинает расти лавинообразно.
Это закон Эрланга в действии. И поэтому Excel врёт, Excel считает средние, а в системах с очередями средние ничего не говорят о реальном поведении.
Ещё одна полезная формула — Закон Литтла, сформулированный в 1961 году:
где L — среднее количество сущностей в системе, λ - интенсивность входящего потока, W - среднее время в системе.
Простой закон, но он позволяет проверять имитационные модели на адекватность. Если ваша DES-модель даёт результаты, не удовлетворяющие закону Литтла, значит модель некорректна и неустойчива.
К теории мы ещё вернёмся в разборе кейса автосервиса во второй части: симулятор проверял эту формулу и поймал важный момент про устойчивость системы, что дало мне важный инсайт о работе системы AS-IS.
Пока что просто запомните: за DES стоит больше 100 лет математики, и она работает.
Откуда DES вообще взялся
В 1961 году инженер IBM Джеффри Гордон выпустил язык программирования GPSS (General Purpose Simulation System) — первый широкодоступный инструмент дискретно-событийной симуляции. GPSS позволял моделировать сложные системы с очередями: производственные линии, телефонные сети, транспортные потоки. Один из первых проектов — система Федерального авиационного управления США (FAA) для распространения метеоинформации в малой авиации. Команда смогла построить модель и получить ответы за шесть недель — раньше такие задачи решались месяцами и стоили в разы дороже.
С тех пор DES прошёл огромный путь. Из инструмента инженеров-исследователей он превратился в стандарт для целых индустрий:
Промышленность и склады. Amazon строит DES-модели для проектирования fulfillment-центров, прежде чем тратить миллионы на оборудование. Toyota использовала симуляцию для отладки конвейерных линий ещё в 80-х.
Здравоохранение. Исследование 2024 года в больнице Burjeel Hospital (ОАЭ) показало, как через DES-моделирование сократили среднее время ожидания пациентов с 37.88 до 29.36 минут путём перенастройки приёмного отделения.
Авиация и логистика. Расписания рейсов, обработка багажа, разгрузка контейнеровозов - всё это сегодня моделируется через DES.
Для глубокого понимания методологии есть устоявшийся англоязычный учебник Banks, Carson, Nelson, Nicol - Discrete-Event System Simulation. С 1984 года он выдержал пять изданий, остаётся стандартом в университетских курсах по имитационному моделированию.
Чего DES не делает
Важно отделить DES от других модных слов, потому что часто их путают.
DES это не Process Mining. Process Mining восстанавливает реальный процесс из логов информационных систем: кто что делал, в какой последовательности, как часто отклонялся от регламента. Это диагностика прошлого по фактическим данным. DES — это прогноз будущего по гипотезам.
DES это не BPMN-описание. BPMN — это нотация, в которой рисуют схемы процессов. Сами по себе схемы ничего не считают. Но BPMN отлично подходит как язык ввода для DES-симулятора: ты рисуешь схему по стандартной нотации, обогащаешь её различными параметрами (данные по потоку заявок, вероятности на «развилках», ресурсы и расписание их работы, стоимость ресурсов, время исполнения задач, стоимость каждой задачи, заработанные деньги, ожидания и т. д. и т. п.), и затем DES-движок прокручивает симуляции и показывает, к чему они привели.
DES это не «предиктивная аналитика». Предиктивная аналитика смотрит на исторические статистические данные, ищет и выстраивает закономерности. DES берёт гипотезу о будущем («а что если мы изменим график») и прогоняет её через модель. Это разные инструменты, и они дополняют друг друга, а не заменяют.
DES это не AI и не нейросети. Это математический инструмент с детерминированными законами поведения, который вы используете для расчета ваших предположений, гипотез, предпосылок. Каждый полученный результат можно объяснить и проверить. По сравнению с «давайте отдадим оптимизацию нейросети» это огромное преимущество, особенно когда речь идёт о бизнес-решениях, которые нужно защищать перед советом директоров или инвесторами, или же которые могут стоить лично вам как собственнику больших денег.
Как я проникся этой тематикой
Упомянутая выше компания, прежде чем выкатить свой новый модуль, объявили чемпионат по дискретно-событийному моделированию — чтобы дать возможность аналитикам «покрутить» и проникнуться этим подходом. В рамках чемпионата нам дали реальный кейс автосервиса, доступ к MVP инструментария DES, необходимый теоретический минимум, два месяца на решение и оперативную поддержку и ответы на все вопросы.
С их точки зрения логика была очевидна: чемпионат — это маркетинг продукта плюс краудсорсинг тестирования. Сто двадцать аналитиков из разных отраслей берут твой инструмент, гоняют его на серьёзной задаче, находят все шероховатости, привозят на блюдечке обратную связь.
С моей стороны логика была другой: мне нужно было быстро понять, насколько данный метод справится с реальной многопараметрической задачей: ресурсы с разными графиками, разные регионы, неравномерные потоки, случайные распределения. Чемпионатный кейс автосервиса по структуре был сложнее, но имел все те же признаки, что и в наших Кайдзен-заявках: поток заявок, разные исполнители, очереди, вероятностные ветвления.
Я подавал заявку без какого-либо расчёта на призовое место. Среди участников были и аналитики из крупных банков, и преподаватели вузов, и консультанты с серьёзным стажем в моделировании. Я планировал тихо разобраться с инструментом, написать какое-то приемлемое решение. Самое главное для меня было — забрать с собой рабочее знание в части имитационного моделирования бизнес-процессов для решения собственных задач.
Дальше две вещи я не предвидел.
Первое — что разбор реального кейса откроет мне глаза на масштаб когнитивных багов, с которыми я лично жил всю карьеру (я знал о них где-то в теории, но прочувствовать — совсем другое дело). Гипотезы, которые я бы ранее поддержал на любой стратсессии без раздумий, при просчёте через симуляцию давали отрицательный результат. И наоборот, контринтуитивные решения, которые я бы как минимум поставил под сомнение, на симуляции показывали серьёзный плюс.
Второе — что работа с имитационным моделированием настолько увлекательна и азартна, что незаметно для самого себя в финале я займу второе место из 120 участников, набрав 271 балл из 300, отстав — от первого места всего на 13 баллов.
К месту я отношусь спокойно — это всё-таки чемпионат и пробный кейс. А вот к первому пункту, к когнитивным искажениям и тому, как интуиция нас обманывает в оценке и планировании бизнес-решений — отношусь очень всерьёз. Это и есть тема следующей части.
Что дальше
В Части 2 — детальный разбор кейса автосервиса с моделью AS-IS, цифрами, узкими местами, проверкой устойчивости через закон Литтла, неудавшимися гипотезами оптимизации, итоговым TO-BE-решением и главным методологическим инсайтом про то, почему маржа после оптимизации выросла всего лишь на 0,8 процентных пункта — и почему это и есть главная победа.
Если же у вас есть похожая задача в вашей компании, и не знаете, имеет ли смысл подключать DES — пишите, буду рад обсудить.