В статье В.В. Репина рассматриваются проблемы применения графических схем бизнес-процессов при решении задачи описания, анализа, реорганизации и регламентации бизнес-процессов компании.
Введение
В последнее время мы с коллегами выполнили несколько проектов диагностики систем управления российскими компаниями. Среди прочих было сделано довольно интересное наблюдение. Оказалось, что руководители подразделений, которые когда-либо проходили обучение или каким-то образом касались в своей деятельности задач описания бизнес-процессов, существенно чётче, более системно представляют себе процессы, в выполнении которых участвует их подразделение. Кроме того, они могут четко и подробно описать действия (процессы), которые они выполняют лично как руководители. Убежден, что для собственников бизнеса этот факт является весьма положительным. Это только один плюс от описания, анализа и регламентации бизнес-процессов из множества полезных для бизнеса возможностей. Но в данной статье мы не будем рассматривать плюсы, а наоборот акцентируем внимание на недостатки, проблемы использования графических схем для понимания и оптимизации реальных бизнес-процессов компании.
Пример процесса производства
Любая графическая схема процесса, по сути, представляет собой алгоритм выполнения работы (Work Flow). Она включает последовательность шагов (действий, операций), события и элементы маршрутизации процесса (логические операторы, шлюзы). Дополнительно можно отображать информационные потоки, сопровождающие поток операций процесса. Независимо от нотации (простая блок-схема, eEPC, BPMN) для описания процесса используются стандартные элементы, хотя условные обозначения могут быть различными.
Для понимания ключевых недостатков любой графической схемы давайте рассмотрим простой пример – производство некоторого изделия. Деятельность состоит из 3-х этапов: сверление, токарная обработка и сборка, как показано на рис.1
Рис. 1. Производство изделия.
С точки зрения бизнес-аналитика, описывающего процесс, получится следующая структура процессов:
1. Процесс сверления:
1.1. зажать заготовку;
1.2. просверлить отверстие;
1.3. ….
2. Процесс токарной обработки:
2.1. зажать заготовку;
2.2. включить подачу;
2.3. ….
3. Процесс сборки:
3.1.приготовить детали;
3.2.соединить деталь А и Б;
3.3....
На рис. 2. показана структура процессов, которую предложил бы бизнес-аналитик. Обратим внимание, что каждый подпроцесс может быть описан в виде алгоритма – последовательности действий, которые должен выполнить соответствующий оператор. На рис. 2. представлен условный пример такого алгоритма.
Рис. 2. Производство изделия. Определены процессы.
Какова ценность алгоритмов выполнения работы? Полезны ли они на практике? Да, безусловно. Анализ действий оператора и последующая оптимизация алгоритма могут повысить производительность работы и сократить потери при выполнении конкретных операций.
Теперь давайте задумаемся над вопросом, какие процессы еще выполняются в данной ситуации, но на нашу схему пока не попали? Отвечая на этот вопрос, получим картинку, показанную на рис. 3.
Рис. 3. Производство изделия. Более полная картина процессов.
А теперь главный вопрос: какая важнейшая информация, с точки зрения возможности оптимизации процесса в целом, отсутствует в рассматриваемой модели? На рис. 4. представлены горы межоперационных запасов (детали, полуфабрикаты), которые находятся до и после каждой операции. Как видно на рисунке, эти запасы распределены неравномерно: где-то больше, где-то меньше (синяя линия показывает путь движения запасов)… Модель процессов совершенно ничего не говорит нам про очереди на обработку деталей, которые существуют перед каждой операцией. Эта информация в алгоритмах процессов не содержится. Так же, в модели нет информации о принципах управления производственной деятельностью. Судя по горам деталей у каждого станка, используется «выталкивающая» система производства. Недостатки ее известны:
производство большими партиями, и, как следствие, длительный цикл поставки продукции;
замораживание оборотных средств в запасах;
значительные потери (брак, переделки, простои операторов и оборудования и т.п.);
нежелание руководителей что-то менять (сокращать время переналадки оборудования, устранять узкие места в процессе и т.п.)
Очевидно, что модель процессов, даже в случае подробного и качественного описания каждого алгоритма, не дает возможности понять реальные проблемы процесса в целом и принять решения по его оптимизации. Эта информация просто находится вне модели. Ее там нет. Итак, можно сделать вывод, что:
АЛГОРИТМ (графическая схема) процесса НЕ СОДЕРЖИТ ИНФОРМАЦИЮ, которая необходима для анализа ЭФФЕКТИВНОСТИ и ВРЕМЕНИ выполнения процесса.
Рис. 4. Межоперационные запасы.
Для тех читателей, которые полагают, что указанные выше рассуждения годятся только для производственным процессов, ниже приводится рис. 5, поясняющий процесс согласования и утверждения договора. В данной, весьма упрощенной модели, Инициатор готовит проект договора и передает на согласование Начальнику отдела. У этого руководителя уже возникает «межоперационный запас» - папка с документами на подпись. Далее на рисунке показаны места, где документы (в т.ч. договоры) накапливаются и хранятся. Очевидно, что возникают очереди на их обработку. Таким образом, процесс, который выглядит простым и понятным на графической схеме в какой-то там нотации, в реальности постоянно прерывается и занимает длительное время…
Рис 5. Процесс согласования и подписания договора.
Резюме
Подводя итоги, стоит рассмотреть разницу между алгоритмом и реальным бизнес-процессом. Для большей наглядности возьмем некоторую автоматизированную систему. Всегда ли в ней будет выполняться алгоритм процесса? Абстрактный – «да», реальный – «нет». Возможны сбои, перегрузки сервера и т.п. Но если отвлечься от этих проблем, алгоритм ВСЕГДА будет выполнен, при условии, конечно, что он является логически корректным.
Реальный бизнес-процесс – совсем другое дело. Как мы уже обсуждали выше, реальный процесс отличается от алгоритма тем, что в нем:
возможен дефицит ресурсов, необходимых для выполнения;
есть очереди ресурсов на обработку;
присутствую межоперационные запасы;
возникают дефекты (несоответствия);
возникают поломки и остановки оборудования и проч.
Что мы наблюдаем на графических схемах процессов, которые создают бизнес-аналитики при описании процессов? Многие схемы даже не имеют корректно выстроенной логики. Но даже если с логикой алгоритма все в порядке, все равно графическая схема (модель) не раскрывает полноты и сложности реально выполняемой деятельности. Использование только одной графической схемы без учета рассмотренных выше аспектов приводит к тому, что у аналитиков не хватает информации для анализа и обоснования мероприятий, которые реально могут повлиять на эффективность и время выполнения процесса. Кроме того, сформированные на основе графической схемы регламентирующие документы могут содержать заведомо невыполнимые на практике требования.
Проектные команды по оптимизации бизнес-процессов могут месяцами искать проблемы и… не находить их. Попадаться будет только всякая мелочь. Главные проблемы сквозного процесса могут оказаться вне области рассмотрения. Поэтому бизнес-аналитикам, занимающимся описанием и анализом процессов, исключительно важно, на мой взгляд, глубоко изучить и освоить принципы и методы Бережливого производства.
В.В. Репин,
к.т.н., Исполнительный директор и партнер ООО «BPM Консалтинг Групп»,
доцент кафедры Бизнес-информатики и систем управления производством Национального Исследовательского Технологического Университета.
Если дополнить схему данными о времени отдельных шагов, то узкие места проявятся.
По максимально медленному участку определится минимальное время такта. Хотя для такого анализа вся схема не требуется, наверное, достаточно перечня шагов. Но для последующей оптимизации нужна будет уже вся схема.
А вот с выводом о возможности невыполнимых требований полностью согласен. Кроме того, в большинстве случаев моделирование одного процесса не учитывает существования других, в которых участвуют те же элементы. Например, станок может быть половину времени задействован в другой цепочке. Переключение станка от одного типа деталей на другой может требовать перенастройки. А необходимость такой перенастройки может возникать как один раз за смену, так и много, если ресурс часто переводится из одного процесса в другой. Даже указав на схеме нормативы шагов по продолжительности можно упустить количество некоторых шагов.
Сразу вопрос - каким инструментом решаются такие задачи?
Нормативное время выполнения отдельной операции не дает возможности рассчитать среднюю длительность процесса в целом. Необходимо создавать имитационную модель процесса. Учитывать все возвраты, переделки и т.п.
Если для группы связанных процессов создать имитационные модели и запустить имитацию, то можно увидеть определенные проблемы, в т.ч. дефицит ресурсов-исполнителей.
Но вопрос в том, что инструменты имитационного моделирования бизнес-процессов очень плохо, ненаглядно работают с такими вещами, как межоперационные запасы и очереди на обработку. Не говоря уже о заданиях (управляющих воздействиях), которые могут менять загрузку операций для разных экземпляров процесса (это вообще невозможно).
Интересным инструментом для анализа является AnyLogic 7. Возможно, при помощи дискретно-событийного моделирования можно описать модель с учетом указанных в статье аспектов.
Отсылка к нарисованным бизнес-аналитиками графическим схемам БП, как это приведено в статье, свидетельствует не о узости или дефектности графических схем, а о слабости рассматриваемых в статье бизнес-аналитиков, которые не имеют достаточного воображения, кругозора и слабо владеют предложенными методологиями и языками моделирования.
Например, на приведённых схемах напрочь отсутствует асинхронность выполнения БП, нет событий исключений и ошибок, эскалаций и синхронизаций, которые вполне реально использовать в моделировании, например, в нотации BPMN, и использовать для последующего практического выполнения процессов.
"...на приведённых схемах напрочь отсутствует асинхронность выполнения БП, нет событий исключений и ошибок, эскалаций и синхронизаций, которые вполне реально использовать в моделировании..."
1. Вообще-то, схем в нотациях в статье нет вовсе (за исключением маленького фрагмента блок-схемы ). Есть иллюстрации содержательного характера. Тем, кто занимается моделированием процессов, не нужно приводить примеры реальных схем. Все и так понятно.
2. "... и использовать для последующего практического выполнения процессов..." - стоит уточнить, что использовать только в соответствующей информационной системе;
3. просьба привести пример схемы в BPMN, которая бы описывала визуально состояние запасов и очереди на их обработку.
По п.2 - разумеется, выполнять схемы, смоделированные с использованием, например, BPMN, можно можно и нужно в тех информационных системах, которые это позволяют, иначе придётся с той или иной степенью трудозатрат переносить в соответствующую среду.
По п.3 - вариант на скорую руку для обсуждения набросал,но не понял, как вставить картинку (((
Задача уже решалась, причем задолго до появления таких инструментов, как BPMN.
См. Теория ограничений, Критическую цепь Элии Голдрата. Что касается графических схем - остается только согласиться с автором, что для оптимизации и анализа этих материалов недостаточно
В статье спутаны основные понятия процесс и модель процесса. Процесс я определяю как необходимость сделать, что то определенное.Например: создать механическое изделие КА-23-2014 согласно договора А-567 от 25,03,2014 года. А модель процесса - рассматривать проблемы применения графических схем при решении задачи описания, анализа, реорганизации и регламентации при работе механического цеха.
При таком подходе можно определить правильная модель была использована или модель не добилась своего предназначения
В случае если реальный процесс не вошел в предложенную модель её можно уточнить или взять другую в зависимости от цели моделирования.
А то что "руководители подразделений, которые когда-либо проходили обучение или каким-то образом касались в своей деятельности задач описания бизнес-процессов, существенно чётче, более системно представляют себе процессы.." не понимают этих различий и выдают одно за другое приводит к неправильной оценке их деятельности (особенно если в модели не учтены основные риски производства изделия).
На мой взгляд, сказано довольно четко: "Подводя итоги, стоит рассмотреть разницу между алгоритмом и реальным бизнес-процессом...."
Действительно разделяю понятия "процесс" и "модель процесса". Спасибо, что еще раз сделали на этом акцент. Это очень хорошо!
Но хотел бы обратить Ваше внимание, что модели могут быть совершенно разные, в т.ч. например дискретно-событийные в AnyLogic или цепочки операций, управляемых событиями, - eEPC. Может быть модель в MS Excel и проч.
В данной статье говорится только о недостатках ГРАФИЧЕСКИХ моделей с точки зрения представления полноты информации о процессе. Не более.
Для вставки картинки нужно ее сначала закачать в свой фотоальбом на данном портале (можно и на любом другом). Над комментарием есть пиктограмма с картинкой - она вставляет код. В него нужно добавит ссылку на рисунок. Например:
Очень хорошая статья. О том, (как я ее воспринял), чего и какими средствами мы хотим достигнуть, и какими средствами и инструментами можем достигнуть в зависимости от потребностей-целей. Ограничено графикой.
Старая истина - "...лучшая модель кошки, это кошка, желательно та же, которая моделируется..." Это, скорее о том, что в принципе любая достойная моделирования модель сложна и сам процесс моделирования, это процесс наблюдения для выявления и выделения в модель того, что интересует, сущностей интереса, и фиксации этих сущностей с целью "анализо-синтеза", предложений улучшения. И такое предложение воспринимаемо лучше всего по классике, "вот так есть, а так вот может быть, и вот дельта улучшений и ее стоимость и цена". Для разных целей, разных моделей одного и того же объекта, к чему подводит автор, нужны и разные подходы и инструменты. AnyLogic, IThik - это "чистые" инструменты для "молчащей" части графических схем бизнес процессов. Ну и в ряде "тяжелых" инструментов моделирования (CM от Casewise, например), есть возможность динамического графического моделирования, что как мне кажется, избавляет в значительной степени от недостатка "немоты" в части ресурс\запрос\очередь. Графическая часть, не меняясь в лице, начинает "говорить" индикаторами. Используется динамическое моделирование достаточно редко. Причины - отдельная тема. Наиболее вероятно отсутствие такой цели и статичность парадигмы мышления моделирующего. Спасибо.
При всем уважении к автору, не кажется ли ему, что усложнение графических моделей бизнес-процессов практической пользы не дает?
В своем генезисе, как один из инструментов TQM, карта процесса - это визуализированная последовательность шагов, необходимая для того, чтобы понимать эту последовательность и видеть общую картину.
Еще необходимы точки контроля, чтобы понимать вкладывается ли процесс в рамки предусмотренных параметров.
Дальнейшее усложнение делает карту процесса вещью в себе.
В кабинетном режиме неэффективность процесса не выявляется и не устраняется. Нужно ходить на гембу, как говорят досточтимые японцы. От себя добавлю, с простой картой процессов.
"...При всем уважении к автору, не кажется ли ему, что усложнение графических моделей бизнес-процессов практической пользы не дает?..."
- спасибо за отзыв, но в статье я не призываю усложнять графические схемы, хотя для некоторых задач такое усложнение неизбежно (например, для имитационного моделирования в eEPC или разработки "исполняемых" схем процессов в BPMN);
- даже простая карта, не содержащая информацию об очередях и запасах, не является достаточно информативной.
Если используемая Вами карта похожа на схему в нотации Toyota Value Stream Map, то да, такой инструмент, вероятно, полезен на практике.
Вас не затруднит привести здесь пример схемы потока, с которой Вы ходите на гембу? Думаю, всем будет интересно и полезно на нее посмотреть.
3. просьба привести пример схемы в BPMN, которая бы описывала визуально состояние запасов и очереди на их обработку.
Владимир, Вы же понимаете, что данная просьба изначально с подначкой.
Безусловно, в чистом "экземплярно-процессном" BPMN, а уж тем более в оставленном за скобками "транзакционном" EPC не предусмотрено элементов, явным образом обозначающих очередь.
Но ...
И сама изначальная схема "Заготовка"-"Обработка"-"Сборка" в BPMN может быть отображена в пределах одного пула только в частном случае единичного производства, ну скажем "Старт (заготовка дров)"-"Срубить елку"-"Распилить елку"-"Наколоть дров"-"Сложить в поленницу"-"Конец (дрова заготовлены)". Здесь и отображение очереди не требуется, она очевидна.
Если же схема описывает реальное промышленное производство, три указанных вида деятельности просто по стандарту придется растащить в разные пулы, потому что в рамках одного экземпляра процесса с общего старта они не уживутся.
А уж дальше всё зависит от цели составления модели.
Если модель нужна чтобы согласовать её с Начальником участка - незачем открывать BPMN-моделлеры. В Визио "шаги рабочего процесса" вполне подойдут.
Если же нужно "погонять" модель на "узкие места" - заказанная Вами "очередь" решается стандартной межпроцессной связью через БД. Ну и что, что среди станков значок БД будет смотреться нелепо - у нас и сами станки превратятся в "квадратики", а весь "производственный цикл" - в токены, бегающие по BPMS-модели. Ну и очередь в этом случае сразу будет видна на отчетах.
(а) модели описывающие активности на производственных участках связать через БД
(которые будут выполнять роль запасов незавершенки")
и
(б) добавить управляющий процесс, который будет анализировать эти БД, сравнивать
из с заданными или вычисляемыми занаряженными и в зависимости от результатов сравнения
запускать \ останавливать активности на производственных участках.
Типа: если сток перед тобой пустой или сток после тебя слишком большой - сиди и кури бамбук
если сто перед тобой непустой и сток после тебя меньше чем нужно - штампуй заготовки )))
Добавить комментарий
Комментировать материалы могут только зарегистрированные пользователи.
Вы можете зарегистрироваться здесь.
). Есть иллюстрации содержательного характера. Тем, кто занимается моделированием процессов, не нужно приводить примеры реальных схем. Все и так понятно.