Новости

18.09.2019
В период с 17 по 18 сентября 2019 года в Москве состоялся авторский тренинг Владимира Репина «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов». Подробнее.
08.09.2019
В период с 5 по 6 сентября в городе Искитим состоялся тренинг по программе «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов» для специалистов компании АО «Искитимцемент». Прочитать отзывы.
08.09.2019
Размещен отзыв компании ООО НПФ «Пакер» о тренинге, который провел Владимир Репин в г. Октябрьский. Прочитать отзыв.
17.05.2019
16-17 мая в Москве прошел тренинг «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов». Ведущий тренинга – Владимир Репин. Подробнее.
27.03.2019
25-26 марта в Томская торгово-промышленная палата прошел тренинг Владимира Репина «Внедрение системы управления бизнес-процессами». В тренинге приняли участие представители компаний: «Сибирская Аграрная Группа», «Элком+», «Системы технологической связи и АСУ ТП», ГК «Лама», ТГУ, Компания «Эскимос», «Сибаналитприбор», «Томскводоканал» и другие предприятия.

18.01.2019
В период с 17 по 18 января 2019 года в Москве состоялся авторский тренинг Владимира Репина «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов».В тренинге приняли участие руководители и специалисты торговой сети «Перекресток».  Подробнее
16.01.2019
Команда BPM3.RU заняла II-е место в рейтинге партнеров компании "СТУ-Софт" и снова включена в "Зал славы партнеров". В нем представлены компании, ставшие лучшими в рейтинге партнеров за последние годы. Это компании, показавшие наилучшие результаты в работе по продажам и продвижению системы Business Studio, успешно оказывающие помощь клиентам в повышении эффективности деятельности и активно популяризующие современные подходы к управлению.

10.01.2019
18 февраля 2019 г., с 18-30 до 21-00 в Москве. Ведущие:
•    Владимир Репин, к.т.н., доцент, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
•    Алексей Петров, бизнес-аналитик, архитектор, автор официального перевода Манифеста гибкости организаций на русский язык
Цель семинара : обсудить практические аспекты интеграции моделей процессов в нотации BPMN в общую архитектуру бизнес-процессов и сквозную модель корпоративной архитектуры, разработанную в программном продукте Business Studio; выявить возможные «плюсы» и «минусы» различных подходов; выработать лучшие решения. Подробнее.
24.11.2018
В период с 22 по 23 ноября 2018 г. в Новосибирске состоялся авторский тренинг Владимира Репина «Моделирование бизнес-процессов в нотации BPMN». В тренинге приняли участие специалисты IT-подразделений Сбербанка России, участвующие в разработке информационных систем (в т.ч. СББОЛ). Тренинг проводился по новой программе на основе книги «Моделирования бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I».

29.10.2018
В период с 25 по 26 октября 2018 г. в городе Березники состоялся авторский тренинг Владимир Репина «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов» для руководителей и специалистов ПАО «Уралкалий». Подробнее.

<< < 1 2 3 4 5 6 7 8 9 10  > >>

Используете ли Вы Business Studio?

Искать

«Простые» схемы бизнес-процессов: «За» и «Против»

«Простые» схемы бизнес-процессов: «За» и «Против

В статье В.В. Репина рассматриваются вопросы разработки «простых» моделей бизнес-процессов при создании репозитория бизнес-процессов компании. Обсуждаются перспективы массового использования сложных нотаций моделирования, возможности упрощения этих нотаций до уровня простых.
        
Уровни зрелости процессного управления

В отчете за 2011 год «Исследование в области моделирования бизнес-процессов», авторами которого являются Пол Хармон и Селия Вулф (BPTrends), приводится модель зрелости организации в области процессного управления, (см. рис. 1).

Концепция уровней зрелости процесса (Process Maturity Levels) была создана в Институте программной инженерии (Software Engineering Institute, SEI)при Университете Карнеги-Меллон в 90-е годы прошлого века. В ее основу положена работа по качеству, первоначально осуществленная Уотсом Хамфри. Впервые разработанная для поддержки анализа зрелости процесса программирования (CMM), последняя версия, интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI), была обобщена для любого из широкого спектра процессов в различных организациях.

Есть основания полагать, что большая часть российских организаций находится  на 1-2, и часть приближается к 3-ему уровню зрелости. Небольшая часть организаций перешла к 4-ому уровню.

 
Рис.1. Обзор основных уровней зрелости по модели СММI

Пример. Компания, в которой давно внедрена система бизнес-моделирования (BPA), создан и используется репозиторий бизнес-процесссов, контролируется исполнение регламентов по процессам, внедрена система управления эффективностью (Business Performance Management) для оперативного мониторинга и управления процессами относится, вероятно, к уровню 4. В такой компании (а это, скорее всего, достаточной крупный, устойчивый бизнес) в штате есть необходимое количество специалистов, профессионально владеющих методами моделирования бизнес-процессов, разработкой и анализом KPI и т.п. Такие специалисты могу осваивать и внедрять сложные методики и инструменты в области управления бизнес-процессами.
 
При анализе практической применимости той или иной нотации (методики) моделирования бизнес-процессов целесообразно учитывать уровень зрелости организации, наличие в ней квалифицированных специалистов. Для компаний, находящихся на 1-2, возможно 3-ем уровне, нужны простые и легкие в освоении методы и инструменты процессного управления.

При использовании сложных методов и «тяжелых» инструментов будет гораздо сложнее вовлекать в работу по внедрению сотрудников компании.  

Для чего моделируют бизнес-процессы?

Это вопрос, пожалуй, кажется настолько банальным и «избитым», что не стоит обсуждения. Но не все так просто, как кажется. В исследовании Пола Хармона приводится следующая диаграмма (см. рис. 2.)

 
Рис. 2. Для чего моделируют процессы

Обратим внимание, что «Как подготовку к применению BPMS» моделирование процессов используют 32% опрошенных. Для реинжиниринга и совершенствования деятельности – 81% опрошенных. В целом, более половины всех опрошенных используют описание процессов для целей анализа и оптимизации, а 51% - для целей регламентации. Таким образом, можно сделать вывод, что на сегодняшний день главной целью моделирования бизнес-процессов является их анализ, реорганизация (оптимизация) и документирование (регламентация, передача знаний через web-портал организации).

На рис. 3 представлена еще одна диаграмма из упомянутого выше исследования.

 
Рис. 3. Наиболее важные свойства средств моделирования бизнес-процессов

Обратим внимание, что только 10% опрошенных считают важным способность легко переходить от модели к коду программного обеспечения. Для остальных более важны другие требования. Например, 36% указало на «Способность создавать простые модели процессов, а 56% на «Способность сохранять модели и данные о процессах в
репозитории». С моей точки зрения эти факты можно интерпретировать следующим образом. Компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации) нужны:
   • простая, но стандартная нотация моделирования;
   • надежный инструмент, позволяющий создавать сложные, многоуровневые модели процессов и хранить их в репозитории (базе данных).

Какие программные продукты класса BPA обречены на «вымирание»  (трансформацию) с точки зрения бизнес-моделирования? Вот их возможные «приметы»:
   • отсутствие репозитория бизнес-процессов (т.е. хранение информации о моделях процессов в файлах, а не в базе данных);
   • использование чрезмерно сложных нотаций моделирования без реальной необходимости;
   • использование нестандартных нотаций;
   • отсутствие возможностей выгрузки информации о процессах в виде регламентирующих документов различного формата;
   • отсутствие возможностей интеграции с web-приложениями для публикации схем процессов и другой информации из модели.

Стоит отметить, что средства моделирования, встроенные в некоторые существующие «легкие» продукты BPMS как раз соответствуют указанным выше «приметам». Вполне вероятно, что разработчики таких систем постепенно будут вынуждены интегрироваться с продуктами класса BPA, которые «умеют» эффективно работать с репозиторием бизнес-процессов компании.

Работа пользователей с таким комплексом продуктов «BPA-BPMS», возможно, будет строиться примерно так:
   1. моделируем процессы в среде BPA (например, в Business Studio);
   2. выгружаем процессы, которые хотим автоматизировать, в средство моделирования BPMS (причем сохраняя нужные для идентификации процесса атрибуты);
   3. дорабатываем модели в средстве моделирования BPMS;
   4. далее используем полученные модели для автоматизации процессов средствами BPMS.

Какую модель бизнес-процесса можно назвать простой?

Рассмотрим деятельность подразделения коммерческой компании, основная задача которого заключается в получении и обработке заявок клиентов, выставлении счетов и т.п. Структура процессов этого подразделения может быть следующая:
   1.  получение заявок клиентов;
   2. обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела);
   3. формирование графика доставки;
   4. обработка «ждущих» (отложенных) заявок;    
   5. контроль остатков, рассылка информационных писем клиентам;    
   6. изменение статуса товара в базе    
   7. обработка отказов.    

На следующем рис. 4 показана модель процесса «Обработка заявки и выставление счета», сформированная в нотации BPMN 2.0. Схема реального процесса была специально упрощена. Тем не менее, она содержит три объекта типа «Gateway» и восемь  объектов типа «Event». Много это или мало?  Можно ли как-то упростить схему?

 
Рис. 4. Фрагмент модели процесса в нотации BPMN 2.0

На рис. 5.  показан тот же процесс, но построенный с использование т.н. conditional flow. Как видим, схема стала проще, но не на много.

 
Рис. 5. Фрагмент модели процесса в нотации BPMN 2.0 с использованием conditional flow.

Какая из схем процессов, показанных на рис. 4 и 5 является более «правильной»? Вероятно, ответить на этот вопрос можно только в контексте конкретной системы BPMS, в которой процесс будет исполняться. Это означает, что интерпретация схемы и механизм использования атрибутов объектов будут зависеть от конкретного программного кода.
    
Рассмотрим тот же процесс, но описанный при помощи нотации «Процедура» в среде моделирования Business Studio (см. рис. 6), причем без использования объекта «решение» (ромб).

Строго говоря, ситуация, обведенная на рис. 6. красным овалом, является нарушением рассматриваемой нотации. Какое же наказание ждет нас за этот «грех»? Нельзя будет корректно выполнить имитационное моделирование для этой модели. Документирование модели в виде регламента процесса можно будет делать точно так же. В данном случае, мы сознательно пошли на упрощение нотации для того, чтобы сделать схему процесса более «простой».


Рис. 6. Фрагмент модели процесса в нотации «Процедура» Business Studio.

Необходимая для понимания «логики» процесса информация представлена в названия стрелок. Другими словами, «условия перехода» между операциями процесса указаны прямо на стрелках.  

Используется два типа стрелок. Стрелки с одним наконечником показываются последовательность выполнения операций, стрелки с двумя наконечниками – информационные потоки. «Межпроцессное» взаимодействие на схеме показано при помощи стрелки с двумя наконечниками («Письмо с заявкой»), которая выходит из межпроцессной ссылки, устанавливающей связь с процессом «Получение заявок клиентов».

Представленная на рис. 6 схема процесса является простой и понятной любому сотруднику безо всякого специального обучения. Практически каждый может описать условия перехода между операциями процесса на стрелках. Конечно, этого мало, чтобы схема процесса была построена корректно (можно неграмотно структурировать сами операции и т.п.). Но это гораздо проще, чем пытаться «моделировать» процесс в «сложной» нотации (рис. 4.)

Отметим, в рамках рассматриваемого подхода стрелки могут содержать информацию нескольких типов:
   • описание события (в  т.ч. в терминах выполненной  работы);
   • описание передаваемой между операциями процесса информации или документа;
   • описание принятого решения или значение какого-либо параметра.

Не всю информацию можно показать на стрелках. Но это и не нужно. Если говорить о регламентации, то схема процесса, как правило, отдельно не используется. Регламент процесса содержит: краткое текстовое описание, графическую схему процесса, подробное табличное описание операций процесса (включая исполнителей и входы/выходы), формы используемых документов и проч. Значительное количество информации о процессе указывается в различных атрибутах его модели. Например, подробное текстовое описание может быть сделано для каждой операции процесса. Применительно к схеме рис. 4. информация о двух днях задержки может быть указана в текстовом описании операции «Запросить уточненные данные по заявке».

Итак, что нам дает «простая» схема процесса (рис. 6)?
При разработке модели:
   • простота и высокая скорость ее формирования;
   • «моделировать» может практически каждый;
   • схема процесса проста и понятна большинству сотрудников, ее легко обсуждать и согласовывать;
   • не требуется специальное обучение и длительная практика  для освоения нотации;
При документировании модели (формировании регламентирующих документов):
   • простота регламентации - в регламент выгружается информация всего по нескольким классам объектов: процесс, стрелка, документ, исполнитель (это не 50 и не 100 разных классов объектов, для которых нужно настраивать шаблоны отчетов);
   • за счет атрибутов объектов модели можно формировать полноценные регламенты (это зависит от средства моделирования – в Business Studio это просто и быстро).
При автоматизации:
   • затраты времени на изменение схемы – экспорт, доработка для преобразования в «исполняемый» формат.

Чего НЕ дает «простая» схема?
   • невозможно использовать ее в качестве «исполняемой» в BPMS;
   • есть риск неоднозначной интерпретации схемы сотрудниками (на мой взгляд, незначительный).

Что нам дает «сложная» схема процесса (рис. 4-5)?
При разработке:
   • требуются значительные трудозатраты на разработку модели процесса;
   • тяжело и долго согласовывать изменения в модели, возможно много разных мнений «как правильно» описать процесс;
   • плохо понятна большинству сотрудников компании, требуется специальное обучение;
   • для разработки требуются опытные специалисты высокой квалификации;
При документировании:
   • вероятно, сложно формировать шаблоны отчетов для выгрузки регламентирующих документов из-за слишком большого количества классов объектов и сложности самих моделей;
При автоматизации:
   • возможность настройки модели и «запуска» процесса на исполнение.

К сложным нотациям можно отнести ARIS eEPC и BPMN 2.0, к простым – «Процедуру» в Business Studio или «Простую блок-схему» в MS Visio. На мой взгляд, к «простым» нотациям стоит относится серьезно. История в разных отраслях человеческой деятельности не раз доказывала, что относительно простые и дешевые решения при массовом использовании существенно эффективнее сложных и дорогих. Если «нотация» не подходит для решения сугубо специальной задачи, но хорошо подходит для решения общих задач в масштабе компании, что будем использовать? У некоторых специалистов возникает искушение упростить «сложную» нотацию до состояния «простой» без потери общности, так сказать. Но что из этого может получиться?

Можно ли упростить «сложную» нотацию моделирования?

Когда среду моделирования бизнес-процессов ARIS «выводили» на российский рынок, описание «методов ARIS» занимало около 1000 страниц текста. Наиболее «ходовая» на тот момент нотация ARIS eEPC содержала большое (несколько десятков) число условных обозначений. В реальных проектах при разработке «Соглашений по моделированию», как правило, создавались «методические фильтры», которые ограничивали количество графически объектов в нотации до разумного и практически нужного (6-8). Фактические никто не использовал все возможные условные обозначения нотации при формировании модели. Но если в ARIS eEPC эти условные обозначения служили скорее для полноты визуального представления процесса, то в BPMN 2.0 они носят более серьезный смысл. Объекты нотации и модели BPMN 2.0 дают возможность создавать «исполняемые» (т.е. автоматизируемые) схемы процессов.

Безусловно, BPMN 2.0 намного сложнее ARIS eEPC. Их даже некорректно сравнивать. Можно обоснованно утверждать, что на сегодня BPMN 2.0 (538 страниц спецификации) является самой «сложной» нотацией (и моделью процесса) в мире. В качестве примера, на рис. 7 приведена таблица с описанием различных вариантов использования событий (event) в BPMN 2.0. И это только события. Есть еще много других сложных объектов. Каково же количество возможных вариантов использования объектов модели? Каково количество возможных комбинаций? Кто из читающих эту статью специалистов по моделированию готов сходу объяснить правила использования каждого события, представленного на рис. 7, и показать практический пример его применения в процессе?


Рис. 7. События в нотации BPMN 2.0

На практике каждая конкретная реализацияBPMN 2.0 в BPMS поддерживает ограниченный набор требований стандарта. Фактически, создаются упомянутые выше «методические фильтры», которые ограничивают палитру используемых объектов. Но возникает вопрос, кто будет создавать эти «методические фильтры» для организаций? Специалисты-практики по моделированию в BPMN 2.0? Вендоры BPMS? Скорее вторые. Практика – критерий истины, даже если она урезанная.

В итоге получится, что один специалист (компания, вендор) создает один фильтр, другой – другой фильтр и т.п. Кто-то назовет свой «способ использования» нотации и модели BPMN2.0 «хорошим стилем», а для кого-то эта модель будет непонятной  -  в спецификации ведь указаны и другие возможности и т.п.

Можно ли будет обмениваться моделями на сайтах или создавать «магазины» готовых моделей в BPMN? Сложно сказать. Вероятно, однако, что «сложная» нотация никогда не станет массовой, и не сможет использоваться всеми сотрудниками компании в качестве рабочего инструмента описания, анализа и документирования бизнес-процессов.

Можно предположить, что со временем появятся устоявшиеся, общепринятые «методические фильтры» для BPMN 2.0, которые обеспечат возможность использования этой нотации более широким кругом специалистов по бизнес-моделированию и рядовыми сотрудникам компаний.

Есть ли альтернатива BPMN? Приведу цитату с одного из сайтов в Интернете: «…Компания Metasonic AG разрабатывает платформу для динамических процессных приложений Metasonic Suite. В ее основу положен уникальный патентованный подход к субъектно-ориентированному управлению бизнес-процессами (S-BPM), разработанный создателем компании доктором Альбертом Флейшманом (Albert Fleischmann). С помощью всего 5 символов бизнес-пользователь Metasonic Suite может создавать собственные управляемые правилами процессные приложения, вносить изменения и немедленно выполнять их на процессном портале. Подход S-BPM ориентирован на субъектов, т.е. людей, принимающих непосредственное участие в процессе. Иными словами, в фокусе S-BPM находится обмен сообщениями между субъектами, а не жестко-централизованный поток работ, как в традиционном BPM. Такой подход, вкупе с возможностями простого и интуитивного описания процессов и их немедленного выполнения на процессном портале, а также гибкой интеграции в имеющийся ИТ-ландшафт, позволяет компаниям существенно повысить свою конкурентоспособность…»


В.В. Репин, к.т.н., доцент, Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

www.finexpert.ru  - всё о процессном управлении!

Январь 2012 г.

Скачать файл со статьей в pdf

Обсудить статью