Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM

Разработка архитектуры бизнес-процессов компании в Business Studio
Опрос

Польза от регламентации процессов для бизнеса:

Библиотека

30.01.2012 18:31
  от автора
  Репин

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

Оценки за материал: 4.50 (4)

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

В отчете за 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 г.

Прикрепленные файлы

Просматривать прикрепленные файлы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.

Комментарии

Оценки: /
30.01.2012 20:36
  от автора
  Петров Дмитрий
Спасибо за статью, Владимир. С общей идеей согласен. Большинству предприятий для анализа, регламентации и оптимизации не нужны сложные нотации, что и подтверждают исследования Пола Хармона. Я бы пошёл ещё дальше и упразднил процессы верхнего уровня (IDEF0 тоже не так прост для рядового пользователя), оставил бы их в виде справочника с распределением ответственности. В Fox Manager, например, мы пытаемся их генерировать автоматически, перенося взаимодействия между процессами нижнего уровня. Получается что-то вроде схемы взаимодействий процессов. Не так красиво, как вручную построенные схемы IDEF0, но зато пользователю удобнее.

Что касается «нестандартных нотаций», поясните Владимир, что Вы имеете в виду? Нотация «процедура» в БС и «простая блок схема» в Visio - это стандартные нотации?

Я не знаю, насколько удачной получилась интеграция BS и Directum (не пробовал), но предложенный Вами вариант интеграции BPA и BPMS мне кажется не перспективным (да и не пойдут на это разработчики BPMS-систем, скорее всего). Слишком разные требования к процессам, которые рисуются для регламентации и для «исполнения» в BPMS. И дело не только в «кубиках», сама логика построения разная и подходы к построению другие и методика определения границ процессов разная. Соответственно процессы, переданные из BPA в BPMS нужно будет очень серьёзно перерисовывать.

Современные BPA-системы уже вышли за пределы задач моделирования деятельности. Даже любимая Вами,, BS содержит динамические элементы (ввод показателей по расписанию через кокпит, модуль аудитов). Так почему бы не добавить функциональность по «исполнению» процессов прямо в BPA-систему? Если идти по пути упрощения и не следовать рекомендациям BPMN 2.0, то реализовать подобную функциональность не так уж и трудно. Мы работаем в этом направлении уже почти полгода, получается довольно удобно.
Оценки: /
30.01.2012 20:58
  от автора
  Репин
Спасибо за отзыв, Дмитрий!

Насчет "нестандатных" нотаций. Критериями определения могут быть:
1. отсутствие спецификации или "фирменного" описания;
2. мало кто использует (редко встречается);
3. используется только в конкретной компании ("самопальная").
Возможно, в статье стоило употребить термин "редко используемая" нотация.

Насчет интеграции BPA и BPMS. Думаю, что такую интеграцию всё таки реализуют некоторые компании. Конечно, не все. В таком решении заинтересованы скорее консалтинговые компании - партнеры разработчиков софта.

Насчет реализации "исполнения" процессов в BPA. Если это сделать, то будет уже другой класс систем. Думаю, что проблема с одной стороны в рыночном позиционировании, а с другой стороны - в наличии необходимых компетенций. Кроме того, если "навернуть" BPA исполняемым движком, то система станет слишком дорогой и сложной для внедрения. Но тема интересная
Оценки: /
30.01.2012 22:00
  от автора
  Дмитрий Пинаев
Не использовать предусмотренный нотацией элемент ромб (он же оператор XOR) - не супер.
Читателем тратится дополнительное время на то, чтобы понять - выходящие стрелки это альтернативные исходы или старт параллельных веток процесса?
Оценки: /
30.01.2012 22:13
  от автора
  Репин
"...Не использовать предусмотренный нотацией элемент ромб (он же оператор XOR) - не супер.
Читателем тратится дополнительное время на то, чтобы понять - выходящие стрелки это альтернативные исходы или старт параллельных веток процесса?..."


- если некорректно именовать стрелки, то схема действительно может стать непонятной. При адекватных формулировках с восприятием схемы все нормально.

Кстати, если использовать XOR, почему тогда не использовать OR и AND? А потом и все остальные необходимые элементы, например BPMN?
Оценки: /
30.01.2012 22:28
  от автора
  Дмитрий Пинаев
>>При адекватных формулировках с восприятием схемы все нормально.
А вот и нет! мне нужно прочесть все три формулировки, чтобы понять, что здесь возможен только один вариант!

>>Кстати, если использовать XOR, почему тогда не использовать OR и AND?
Есть некоторый базис, не используя которого ты ничего не нарисуешь .
AND - это как раз несколько исходящих стрелок из блока.
Нет только OR, т.к. редко используется. Если бы использовался часто, пришлось бы вводить и его.
Оценки: /
30.01.2012 22:32
  от автора
  Репин
Это у меня conditional flow в "Процедуре" Business Studio
Оценки: /
30.01.2012 22:36
  от автора
  Дмитрий Пинаев
Официально заявляю, что BS о таком и не слыхивала!
Оценки: /
30.01.2012 22:45
  от автора
  kaloshina
Владимир, статья интересная, и как всегда жизненная. Меня, как пользователя, 7 рисунок отпугивает, логика с первого взгляда ясна только одна "жирным кругом обводится завершение".

"Читателем тратится дополнительное время на то, чтобы понять - выходящие стрелки это альтернативные исходы или старт параллельных веток процесса?..."
Одна компания, кстати, решила эту проблему так: после блока решения все неправильные и некорректные исходы (стрелки) красят в красный цвет. Правда, трудоемко, зато наглядно
Оценки: /
30.01.2012 22:47
  от автора
  Петров Дмитрий
kaloshina

Одна компания, кстати, решила эту проблему так: после блока решения все неправильные и некорректные исходы (стрелки) красят в красный цвет.

В каком смысле "неправильные" и "некорректные"?
Оценки: /
30.01.2012 23:03
  от автора
  kaloshina
Дмитрий, например, сотрудник осматривает внешний вид упаковки, если все в порядке (1 стрелка), то подписывает документы, если нет (2 стрелка), то товар переупаковывают, и сотрудник снова осматривает внешний вид упаковки. Вот 2 стрелку и делают красной.
Оценки: /
31.01.2012 00:00
  от автора
  Дмитрий Пинаев
Людмила, на каких принтерах они печатают схемы?
Оценки: /
31.01.2012 10:39
  от автора
  kaloshina
Дмитрий, на цветном кстати, на цветном А3

Но красный цвет - как один из вариантов решения. Как и все варианты - кому-то удобно, кому-то нет
Оценки: /
31.01.2012 11:59
  от автора
  gundorov
Спасибо Владимиру за очередную интересную статью!

Простота восприятия схем процессов играет немаловажную роль при описании процессов. Разный уровень подготовки специалистов Заказчика, цели и решаемые задачи консалтингового проекта, каждый раз подводят к проблеме выбора той или иной нотации.
Для описания процессов верховного уровня, наилучшей выбор - IDEF0, большинство Заказчиков легко воспринимают эту нотацию, а вот при описании workflow иногда возникает проблема, что выбрать - EPC, Процесс или Процедуру (в терминологии Business Studio). Основной критерий выбора - простота понимания Заказчиком модели процесса в выбранной нотации (другие факторы тоже имеют значение). Большинство выбирает "простые" нотации - Процедуру и Процесс и не последнюю очередь, потому что там есть привычный блок принятия решения, т.е. "ромб".

Владимир предлагает упростить схемы и убрать объект "решение" (т.е. ромб), а выбор определять с помощью наименований стрелок. В этом случае схемы станут как минимум короче, т.е. более "простыми", но станут ли они от этого более понятными и даст ли это необходимые преимущества? На мой взгляд, эффект может быть прямо противоположным:
• при отсутствии "ромба" альтернативные стрелки визуально определяют не выбор, а параллельное исполнение, схему сложнее анализировать;
• в случае отказа от использования ромба, отказ должен быть тотальным (т.е. нельзя в одном случае ромб указывать, а в другом нет), что вряд ли возможно;
• простота и высокая скорость формирования может обернуться низким качеством модели;
• легкость согласования и обсуждения "простых" диаграмм несложных процессов в одном случае, оборачивается трудностями согласования и обсуждения "простых" диаграмм сложных процессов в другом случае;
• при автоматизации, возрастает время на понимание алгоритма задач.
Если говорить о преимуществах "простой" модели применительно к моделированию в Business Studio то их попросту нет: используются общий набор классов объектов, аналогичные шаблоны и т.д.

Владимир прав, считая что надо стремится к простоте, но не всегда «простота» является наилучшим выбором. Легкость и простота создания и использования «простых» диаграмм может сопровождаться легкостью и простотой получения ошибок и заблуждений.

P.S. Могу ошибаться, но мне кажется что комплекс продуктов «BPA-BPMS» в перспективе не является жизнеспособным. Если не путаюсь в терминологии, BPA является частью BPMS и судя по тенденции либо отдельные продукты BPA вырастут до BPMS либо умрут, BPMS в свою очередь обязательно нарастят функционал своих инструментов моделирования до уровня современных BPA (либо умрут )
Оценки: /
31.01.2012 12:10
  от автора
  jjvadik
Спасибо Владимир за интересную статью.
Кто то сказал, что объяснить гениальное просто - вот истинный гений ))
А по уровням зрелости процессов мне больше нравиться шкала Gartner (http://www.gartner.com/id=497289)
Оценки: /
31.01.2012 13:49
  от автора
  Дмитрий Пинаев
BPA - это не часть BPMS. Это средство анализ процессов с функционалом: моделирование, симуляция, контроллинг.
Системы, где больше моделей - это Eneterpise Architecture. В EA обычно есть стратегия, процесссы, оргструктура, данные, ИТ-ландшафт.

Оценки: /
31.01.2012 14:27
  от автора
  Богиня
Спасибо,Владимир за статью! Для чего моделируют бизнес-процессы?
В свою очередь я бы продолжила список: 1.Как инструкцию по выполнению работы для вновь входящих сотрудников, а также для сотрудников заменяющих друг-друга.2. Для выбора процессов,которые можно автоматизировать,во всяком случае видно будет наглядно.
использование нестандартных нотаций;. Простите, а какие нотации приняты, как стандартные?
Фрагмент модели процесса в нотации BPMN 2.0 с использованием conditional flow,кажется более простым и понятным,нежели в нотации Процедура,потому как последовательность выполнения тех или иных действий понятна.
Оценки: /
31.01.2012 14:38
  от автора
  Репин
Коллеги, спасибо за отзывы о статье!

"...Владимир прав, считая что надо стремится к простоте, но не всегда «простота» является наилучшим выбором. Легкость и простота создания и использования «простых» диаграмм может сопровождаться легкостью и простотой получения ошибок и заблуждений..."

- ошибки и заблуждения при моделировании возможны в любом случае. Но в какой ситуации сотрудник компании, не обученный и неопытный в области моделирования процессов, допустит больше ошибок? При использовании относительно "простой" или "сложной" нотации?

"...Владимир предлагает упростить схемы и убрать объект "решение" (т.е. ромб), а выбор определять с помощью наименований стрелок. В этом случае схемы станут как минимум короче, т.е. более "простыми", но станут ли они от этого более понятными и даст ли это необходимые преимущества? На мой взгляд, эффект может быть прямо противоположным:
• при отсутствии "ромба" альтернативные стрелки визуально определяют не выбор, а параллельное исполнение, схему сложнее анализировать;..."


- риск такой есть, но если корректно и подробно именовать стрелки (т.е. по сути указывать на них условия перехода), то отсутствие ромба проблемы не вызывает. Кстати, полученная схема ближе к DFD, чем к Work Flow.

"... • в случае отказа от использования ромба, отказ должен быть тотальным (т.е. нельзя в одном случае ромб указывать, а в другом нет), что вряд ли возможно;.."

- в рамках конкретного проекта и репозитория процессов - да. Никто ведь не призывает это сделать всеобщей практикой

"...• простота и высокая скорость формирования может обернуться низким качеством модели;"

- что есть "качество" модели? Все зависит о контекста и задачи. Можно собрать космический спутник, а можно велосипед. Но если нужно проехать 2 км., то велосипед подойдет лучше .Если серьезно, то понятие "качество" (в т.ч. качество модели) всегда относительно. Оно зависит от целей моделирования, контекста компании отведенного времени и т.п.

"...• легкость согласования и обсуждения "простых" диаграмм несложных процессов в одном случае, оборачивается трудностями согласования и обсуждения "простых" диаграмм сложных процессов в другом случае;..."

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

"...• при автоматизации, возрастает время на понимание алгоритма задач..."

- возможно, хотя довольно спорно. Смотря кто будет автоматизировать, и в какой системе.
Оценки: /
06.05.2012 12:22
  от автора
  bell
Ай-яй-яй, какой некрасивый прием.

Объясняю. BPMN позволяет создавать -
1) простые "аналитические" схемы, используя для этого небольшую часть палитры (в частности, никаких событий).
2) очень точные и детальные "исполняемые" схемы, но они, естественно, получаются более сложными.

По контрасту с BPMN, IDEF0 и прочие "кросс-функции" и блок-схемы позволяют создавать только простые, но при этом с неизбежностью не слишком детальные схемы.

Скажите, такая "двунацеленность" BPMN - это хорошо или плохо? По-моему, это хорошо.

Что же делает автор? Вместо того, чтобы сравнивать "яблоки с яблоками" - аналитическую диаграмму BPMN с аналитической же диаграммой в какой-то другой нотации, он рисует в BPMN искусственно усложненную диаграмму, чтобы показать какая эта бяка.

Хотя можно было нарисовать вот так:

[img]bpmnforum.ru/?bb_attachments=843&bbat=371[/img]

Неужели она сложнее образца, который представил Владимир?

Сравнивая эту схему со схемой, предлагаемой автором в качестве образца, хочется заметить следующее:
1) Логика переходов у Владимира хромает: при первом проходе через задачу "Обработать заявку (письмо) клиента" не может быть варианта "Клиент отказался от покупки". На самом деле тут две развилки, и отказ от покупки является одним из возможных исходов обращения к клиенту за уточненными данными.
2) У процесса есть два существенно разных выхода: успешное завершение и отказ от покупки. Сводить их к одному "конец процесса" мне представляется менее наглядным.
3) Представлять клиента в качестве дорожки не очень хорошая идея, более корректно изображать его в качестве внешней сущности. Ну не можем мы назначать задачу клиенту так, как мы это делаем своему сотруднику (в данном случае - оператору). В BPMN этот момент четко схвачен, в отличие от...

Ну и не могу оставить без ответа (положение обязывает) некоторые безосновательные выпады в адрес BPMN и BPMS. (Думаю, Владимир рассчитывал получить от меня аргументированные возражения - жалею, что увидел статью только сейчас.)


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



  1. Все известные мне BPMS хранят модели процессов в репозитории.
  2. Использование чрезмерно сложных нотаций без реальной необходимости - это проблема аналитика, а не инструмента, что нам Владимир убедительно продемонстрировал. При этом необходимо отметить (извините за повторение), что BPMN имеет выразительные средства для моделирования сложных процессных задач на детальном уровне, а предложенная альтернатива - нет.
  3. Что касается стандартности нотаций, то все ведущие BPMS используют BPMN. Точность соблюдения стандарта пока не идеальна, но ему (BPMN 2.0) всего год от роду. Дайте срок. А каким стандартом описываются кросс-функциональные диаграммы?
  4. К примеру, Bizagi умеет выгружать описание процесса в Word, Visio, PDF, ну и в графику, естественно. Этого достаточно?
  5. К примеру, Bizagi умеет публиковать описание процесса в SharePoint, в Wiki, в HTML. Этого достаточно?


Относительно Метасоника и 5 символов. Я вам больше скажу: имея в своей палитре всего 1 (один!) пиксел можно нарисовать все что угодно. Если серьезно, то Метасоник - это кот в мешке. Даю подсказку: наберите S-BPM в Google Trends. И для сравнения, скажем, BPMN и IDEF0. Масса вопросов отпадет.

Но больше всего мне интересно какую статью напишет Владимир, когда в Business Studio в конце концов появится BPMN.
Оценки: /
06.05.2012 12:24
  от автора
  bell
Картинка не вставилась, пробую еще раз
[img]http://bpmnforum.ru/?bb_attachments=843&bbat=371[/img]
Оценки: /
06.05.2012 12:26
  от автора
  bell
Не могу справиться с движком сайта. Придется дать ссылку схема процесса в "правильном" BPMN
Оценки: /
07.06.2012 18:33
  от автора
  chromosome
Являюсь полным новичком в сфере бизнеса и удивляюсь как схемы бизнеса могут быть "простыми". В любом случае, надеюсь что смогу добиться таких же высот и писать такой же превосходный материал.

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений