Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по 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 Digital Directum

Опрос

Вы используете

Библиотека

17.11.2011 13:08
  от автора
  kaloshina

Сравнительный анализ нотаций моделирования бизнес-процессов

Оценки за материал: 4.60 (5)

Не вполне корректно называть моделью процесса диаграмму описывающую только отдельные аспекты поведения бизнес-процесса. Модель процесса есть взаимоувязанное описание Функциональной, Поведенческой, Информационной и Организационной перспектив. Для описания Поведенческой перспективы следует использовать Диаграмму потока управления, которая дает исчерпывающий ответ на вопрос «Как исполняется процесс» и, включает бизнес-логику, бизнес-правила, расписание исполнения, имеет детализацию уровня действий и описывает все возможные сценарии исполнения. Диаграмма потоков работ, которую не вполне обоснованно называют моделью процесса, не описывают все многообразие поведения процесса и не в полной мере дает описание динамики процесса. Можно констатировать, что многие модели, которые используются в практике реинжиниринга, не удовлетворяют всем перечисленным требованиям, предъявляемым к процессным, и потому не могут называться процессными.

Автор: Игорь Федоров
Опубликовано: http://www.osp.ru/os/2011/08/13011140/
Сейчас очень популярно сравнивать нотации и языки моделирования бизнес-процессов (БП) [1,2]. Анализу подвергаются возможности нотаций для описания процессов [3,4], синтаксис и набор примитивов языка описания и т.д. Однако, как будет показано в данной работе, сравнивать нотации и языки описания процесса путем анализа их функциональности не вполне корректно.
Цель настоящей работы в том, что бы сравнить нотации и методы моделирования с учетом используемых методологий. Мы попытаемся уточнить понятие процессной модели. Наше утверждение: не нотация, а методология определяет, является ли модель функциональной или процессной.

Модели и перспективы

Моделью принято называть некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого прототипа. Модель в достаточной степени повторяет одни свойства, существенные для целей конкретного моделирования, и опускает другие, несущественные свойства, в которых модель может отличаться от прототипа.
Сложный объект, коим является БП, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей называется перспективой [5], с ней связан главный вопрос, на который должна давать ответ соответствующая модель. Первоначально, выделялись четыре перспективы модели БП:
1.      Функциональная: отвечает на вопрос: «Что делают участники?», описывает состав выполняемых работ.
2.      Поведенческая: отвечает на вопрос: «Как работают участники?», описывает очередность, расписание выполнения, бизнес-правила.
3.      Информационная: отвечает на вопрос: «Что обрабатывают участники?», описывает бизнес сущности, предметной области процесса.
4.      Организационная: отвечает на вопрос: «Кто выполняет работу?», описывает состав и структуру исполнителей.
Было бы слишком прямолинейно полагать, что модель, описывающая какую-то перспективу, отвечает только на один вопрос. Вопросов м.б. несколько, каждый определяет отдельный аспект перспективы, но среди них всегда есть главный, на который модель должна дать исчерпывающий ответ, а на дополнительные вопросы модель может полностью не отвечать. В последнем случае надо быть особенно внимательным, перспектива модели определяется именно главным вопросом, а не вспомогательным. На Рисунке 1 показаны различные перспективы модели процесса и вопросы, на которые они отвечают.


Рисунок 1. Перспективы процесса

Функциональная перспектива


Функциональная модель описывает статику системы, помогает ответить на вопрос «что надо делать, что бы достичь поставленной цели?». Это перечень всех тех действий, которые необходимо выполнить, что бы добиться запланированного результата. Функциональная декомпозиция мощный элемент анализа БП, она помогает понять логику процесса и не забыть выполнить какую-либо важную функцию.
Часто функциональную модель ошибочно называют картой процессов. В качестве примера назову модели SCOR, ETOM, которые сдержат иерархии функций и цепочки создания ценности, но отнюдь не процессы [6] в нашем понимании. Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы


Поведенческая перспектива, описывающая динамику системы, отвечает на вопрос «Как работают участники?». Для ее моделирования используется диаграмма потоков управления. Давайте разделим основной вопрос «Как?» на три под вопроса:
•      В какой очередности выполняются операции, образующие процесс?
•      В какое время выполняется операция?
•      Почему операции исполняются в заданной очередности?
Ответ на первый вопрос дает бизнес-логика, которая представляет процедурное описание очередности исполнения работ, для ее графического отображения используется диаграмма потоков работ.
Ответ на второй дает расписание исполнения процесса. Расписание определяет: когда выполняется та или иная работа, время, затрачиваемое не ее исполнение, действия, предпринимаемые в случае, когда расписание нарушено.
Наконец ответ на третий вопрос дают бизнес-правила, являющиеся декларативным описанием ограничений, накладываемых на процесс.
Рассмотрим три аспекта поведенческой перспективы более подробно.

Бизнес-логика процесса


Очередность операций, образующих процесс, принято называть бизнес-логикой, для ее описания применяются диаграммы потоков работ (в качестве примера назовем UML, EPC, Flowchart).
Бизнес-логика содержит явные, предписывающие сведения о маршруте исполнения процесса, но лишь косвенно учитывает критерии принятия соответствующих решений. Описание бизнес-логики процесса включает элемент Ветвление, который позволяет направить исполнение процесса по одному из предопределенных маршрутов в соответствии с заранее заданными условиями. Ветвление есть элемент бизнес-логики процесса, а условие, по которому осуществляется ветвление, есть бизнес- правило.
Диаграммы, описывающие бизнес-логику, визуально кажутся простыми и понятными, поскольку не включают бизнес-правила, график исполнения, корректирующие действия, выполняемые, когда показатели процесса выходят за рамки допустимых диапазонов, поэтому многие аналитики используют их для согласования с представителями бизнеса. Однако простота обманчива, разработчикам ИТ систем приходится повторно собирать пропущенные сведения, причем их представление о процессе может существенно отличаться от взглядов аналитика. Возникает опасная ситуация, модель не в полной мере описывает процесс, детали не фиксируются явно, а существуют в головах программистов, что является одной из причин, почему модель процесса на бумаге не соответствует логике работы ИТ системы.

Бизнес правила


Под бизнес-правилом принято понимать утверждение, определяющее или ограничивающее некоторые аспекты бизнеса. В отличие от процедурного описания, правила постлируют ограничения на исполнение процесса, но не определяют, как предполагается достичь результата. Известный специалист в области бизнес правил Рональд Росс определяет следующую классификацию бизнес-правил[7]:
1.      Правила поведения: определяют необходимость выполнить соответствующее действие, осуществить управляющее воздействие.
2.      Правила определения: устанавливают критерий применимости какого-либо бизнес понятия, называемого фактом, подразделяются на:
•      Правила вычисления, помогают узнать значения искомых величин, называемых фактами. Например, торговая скидка может определятся общим объемом закупок за определенный период и т.д.
•      Правила классификации, помогают проверить истинность фактов. Например, клиент считаеся VIP, если на его счете имеется определенная сумма денег и он не имел задолжности по платежам.
Как мы выяснили выше, ветвления процесса осуществляется на основе Правила Поведения, которое принимает значения Истинно и Ложно, но что есть Истинно, а что есть Ложно, определяется Правилом Классификации. В свою очередь, последнее должно получить на вход некоторое значение, которое, можно предположить, получено с использованием Правила Вычисления. Например, представим следующую последовательность действий: вычислить величину скидки как функцию от размера текущего заказа (Правило Вычисления), классифицировать размер скидки: большая, средняя, низкая (Правило Классификации) и, наконец, отправить сделку на одобрение руководителю с соответствующим уровнем полномочий (Правило Поведения).
Однако, распространенная практика моделирования - фиксировать на схеме правило ветвления, забывая про правила определения. Отсутствие в модели критериев принятия решения делает диаграмму потоков работ не полной.
Из сказанного следует практическая рекомендация – следует явно выделять Правила определения в отдельные конструкции на диаграмме потоков работ. Это поможет аналитику четко локализовать соответствующую логику.

Расписание исполнения процесса

В области материального производства хорошо известен график выполнения работ, который используется для расчета времени, затрачиваемого на производство изделия. Для бизнес-процессов график работ имеет более сложный вид, поскольку каждая операция может исполняться вовремя, а процесс целиком с опозданием, из-за возвратов назад на повторную обработку.
Онтология времени, используемая для описания бизнес-процессов, использует два базовых понятия: События и Интервалы[8]. Под Событием понимается точка на шкале времени, не имеющая длительности. События используются для координации исполнения разных процессов или ветвей одного процесса. Под интервалом понимается отрезок на шкале времени, заключенный между начальным и конечным Событиями. Интервалы позволяют определить лимит времени, отводимый на исполнение отдельной операции или группы операций.
Можно предположить, что диаграммы для описания процесса должны оперировать этими же понятиями. Однако диаграммы потоков работ не содержат таймеров для интервалов времени. В нотации EPC присутствует конструкция Событие, однако обычно она используется не по прямому назначению. По установившейся практике, аналитики используют элемент Событие для обозначения состояния объекта управления. Как следствие, события не описывают синхронизацию исполнения. Можно говорить, что диаграмма потоков работ не моделирует расписание исполнения.

Степень детализации бизнес-логики процесса


Что бы ответить на вопрос «Как?», диаграмма процесса должна содержать максимально подробное описание действий, образующих процесс. Многие аналитики ограничиваются перечислением функций, без указания деталей их исполнения. Этот подход предполагает, что исполнитель знает, как следует выполнить работу. Однако на практике сотрудники склонны выполнять работу с учетом своего индивидуального опыта, приобретенного на предприятиях с отличной организацией труда и производственной культурой, что приводит к высокой вариативности исполнения процесса.
Руководящий документ Госстандарта России, «Методология Функционального Моделирования IDEF0» [9] вводит понятия Действия и Операции. Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а Операция - как «совокупность последовательно или/и параллельно выполняемых Действий».
Попробуем уточнить эти определения для случая моделирования процессов. Действием будем называть работу, выполняемую участником над объектом процесса, изменяющую этот объект, но не приводящую к смене его состояния. Например, участник ввел новые данные, но это не означает окончания обработки документа. Операцией будем называть совокупность действий, приводящая к изменению состояния объекта.
Диаграмма потоков работ обычно ограничивается уровнем операций. Считается, что излишняя детализация затрудняет понимание логики процесса. Напротив, исполняемые модели оказываются излишне подробными, как следствие, рискуют оказаться перегруженными деталями, определяющими ограничения на потоки управления и данных, распределение работ между участниками, что делает их более сложными для понимания.

Степень полноты бизнес-логики процесса


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

Модель процесса, диаграммы управления и потоков работ

Следует различать диаграммы потоков работ, управления и модель процесса. Диаграмма потоков работ определяет бизнес-логику, очередность исполнения операций, ограничивается описанием отдельных вариантов исполнения, имеет детализацию уровня операций, не включает расписание исполнения процесса и может не определять бизнес-правила процесса полностью.
Диаграмма управления уточняет диаграмму потоков работ в части расписания исполнения и бизнес-правил, имеет детализацию уровня действий, она должна описывать все варианты исполнения. Иначе говоря, она описывает технологию, гарантирующую достижение запланированного результата в случае точного выполнения заранее определенного набора действий. В отсутствие хотя бы одного компонента, описание окажется неполным, технология не будет соблюдена.
Наконец модель процесса есть совокупность взаимоувязанных перспектив, каждая из которых описывает отдельные аспекты поведения процесса, а все вместе они образуют интегрированное, комплексное и полное представление о процессе и его исполнении. В том числе, диаграмма потоков управления описывает поведенческую перспективу модели бизнес-процесса.

Обсуждение: почему возникают проблемы трансляции диаграммы EPC в исполняемый формат


Результаты моделирования в нотации EPC не всегда приводят к созданию модели, которая м.б. конвертирована в исполняемый формат BPM без существенных переделок [10]. Постараемся перечислить возможные причины таких неудач.
Нотации, включенные в ARIS, обладают чрезвычайно широкими возможностями по моделированию процессов, но, к сожалению, они не подкреплены открытыми и доступными для пользователей методологиями. Находящийся в открытом доступе документ, называемый «Методология ARIS» [11], описывает не методологию, а правила применения нотации, что допускает широкие возможности по «интерпретации» способов моделирования.
Недостатки часто оказываются продолжением наших достоинств. Проблема EPC, как мне кажется, связана с попыткой приспособить этот инструмент для решения слишком широкого круга задач, но без объяснения правил применения для конкретного случая. Как результат, аналитики применяют многие конструкции и механизмы интуитивно и неосознанно. Иногда удается понять их замысел из контекста задачи, но нельзя предположить, что машина сможет проанализировать контекст автоматически, в ходе преобразования диаграммы в исполняемый формат. Перечислим типовые ошибки:
•      У не очень опытных аналитиков модель EPC описывает наиболее вероятный вариант исполнения, опуская редко используемые альтернативные маршруты, на схеме редко встретишь описания действий в нестандартных и исключительных ситуациях.
•      Изменение объекта управления по ходу процесса является крайне распространенным явлением. Представим себе описание технологического процесса, включающего изготовление комплектующих. Если комплектующие производятся под заказ, можно включить описание их изготовления в основной процесс, но если комплектующие производятся асинхронно от основной детали, их производство д.б. отдельным процессом со своим объектом управления. Аналитик должен тщательно следить за объектом управления процесса т.к. его смена является признаком возможного разделения сквозного процесса на цепочку взаимодействующих процессов. Аналитические модели EPC игнорируют смену объекта управления.
•      Недостаточная степень декомпозиции процесса приводит к необходимости повторно уточнять и описывать упущенные детали процесса на этапе подготовки требований к разрабатываемой ИТ системе.
•      Диаграммы EPC не описывают расписание исполнения, опускают вопросы синхронизации ветвей одного процесса между собой и с другими, внешним процессами. Диаграмма EPC включает конструктивный элемент Событие, который, мог бы быть полезен для описании синхронизации процесса. Однако, в силу отсутствия четких методических указаний, эта конструкция используется аналитиками для описания состояния продукта процесса.
Подводя итог, можно сказать, что проблемы применения EPC лежат, в большей степени, в области методологии ее применения. Можно предположить, что при наличии соглашения о моделировании, которое бы определяло все детали разрабатываемой модели, многих проблем удалось бы избежать.

Выводы


Мы поставили цель показать, что не нотация, а методология определяет, является ли модель функциональной или процессной. Проведенный анализ позволил сделать следующие выводы:
Модель процесса есть многослойное описание, включающее взаимоувязанные описания Функциональной, Поведенческой, Информационной и Организационной перспектив.
Для описания Поведенческой перспективы следует использовать Диаграмму потока управления, которая дает исчерпывающий ответ на вопрос «Как исполняется процесс» и, в том числе, определяет последовательность операций, бизнес-правила, расписание исполнения, имеет детализацию уровня действий и описывает все возможные сценарии исполнения
Диаграмма потоков работ, которую не обоснованно называют моделью процесса, не описывает всех деталей поведения процесса и не является процессной диаграммой. Можно констатировать, что многие модели, которые используются в практике реинжиниринга, не удовлетворяют всем перечисленным требованиям и потому не могут называться процессными. Вдумаемся, Хаммер и Чампи [12] призвали нас заменить функциональное управление на процессное, а мы, что бы реализовать их призыв, производим функциональное моделирование бизнес-процессов (БП). Возникает законный вопрос: можно ли переходить к процессному управлению через функциональное моделирование, нет ли тут противоречия? Может в этом кроется неудача многих проектов реинжиниринга БП?

Литература:

1.      Stein, Dr. Sebastian. EPC vs. BPMN - the perfect flamewar. ARIS Community. [Online] Software AG, 04 15 , 2010. http://www.ariscommunity.com/users/sstein/2010-04-15-epc-vs-bpmn-perfect-flamewar.
2.      van der Weel, Harald. Will BPMN completely replace EPC? BrainStormCentral. [Online] 1 16, 2011.
3.      Kiepuszewski В., ter Hofstede A.H.M., van der Aalst W.M.P.: Fundamentals of Control Flow in Workows,
4.      Schluchter, S. SAP Network Blog: BPMN or EPC? SAP Network Blog. [Online] 07 14, 2006. [Cited: 02 14, 2010.] http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3974.
5.      Curtis, B., M., Kellner and Over, J. Process Modeling. 1992. pp. 75-90.
6.      eTOM, Representative process flows. ITU. s.l. : TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU, 2004.
7.      Ross R., Principles of the Business Rule Approach. Addison-Wesley Professional(2003).
8.      Pedrinaci1 C., Domingue ., Alves de Medeiros A., A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008
9.      МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0. Москва : ГОССТАНДАРТ РОССИИ, 2000.
10.      Tscheschner, W. Transformation from EPC to BPMN. [Online] http://bpt.hpi.uni-potsdam.de/pub/Public/OryxResearch/TransformEPC2BPMN.pdf.
11.      Methods ARIS 7.0. Saarbrücken : IDS Scheer AG, 2005.
12.      Hammer, M. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review. July-August 1990, pp. pp104-112.

Комментарии

Оценки: 1/
17.11.2011 15:07
  от автора
  Репин
Спасибо Игорю Федорову на продуманную, глубокую и качественно написанную статью! Снимаю шляпу! Побольше бы таких статей...

Некоторые соображения по тезисам статьи.
На 100% согласен, что "...Не нотация, а методология определяет, является ли модель функциональной или процессной..." Нотация сама по себе просто набор элементов и правил связи, а методология - руководство к ее применению для получения конкретного практического результата.

Но результаты и его ценность для потребителя могут быть разными. Поэтому не соглашусь с тезисом Игоря: "...Диаграмма потоков работ, которую необоснованно называют моделью процесса, не описывает всех деталей поведения процесса и не является процессной диаграммой". Процесс может быть описан без лишней детализации, минимальными средствами и при этом быть полезным как для анализа и регламентации, так и для автоматизации (не в BPMS, а в других системах).

Модель, содержащая детальное описание потов управления:
а) сложна для восприятия, анализа, обсуждения и принятия решений;
б) является весьма дорогой при разработке.
Стоит ли отражать в этой модели все возможные ситуации, ссылаясь на необходимость автоматизации в BPMS? Можно составить полное описание всех ситуаций, потратить на это много времени и денег, а по реально потребуются только 20% из них (приницип 20х80). Остальные на практике будут встречаться настолько редко, что вопрос можно будет решить традиционными средствами (личное взаимодействие людей по телефону и т.п.).

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

Далее. В статье не затронуты вопросы удобства и наглядности схем процессов для аналитиков и рядовых исполнителей. Ни ARIS eEPC, ни BPMN в этом отношении далеко не идеальны. Кроме того, чисто с технической точки зрения (количество кликов) трудоемкость создания моделей в этих нотациях достаточна высока. Напомню тезис, что только 6-8% операционных процессов компании нуждаются в автоматизации в BPMS. Остальные - в офисных приложениях, клиент-серверных системах. Т.е. для описания 90% процессов компании нужна более простая и понятная сотрудникам нотация, нежели ARIS eEPC/BPMN. Замечу, что не всю информацию нужно помещать на графическую схему процесса. Например, правила (поведения, определения, вычисления, классификации) можно задать в текстовом описании операции процесса. Исполнитель получит регламент, содержащий графическую схемы и таблицу с подробным описанием своих действий. Т.е. задача регламентации действий будет решена без разработки сложной модели.

BPMN "стал стандартом "де-факто" - что из того? Для кого стал? Для людей, чей бизнес связан с продажей соответствующего софта. Но руководители и сотрудники хотят заниматься реальной работой, а не описывать бесконечно эту работу в нотации eEPC/BPMN. Для решения задачи описания, анализа (зоны безответственности, дублирование, бестолковый ручной труд и проч.) и регламентации процессов нотации eEPC/BPMN избыточны! Кто-то наконец предложит нотацию, которая удобна для сотрудников компании, а не только для узкого круга аналитиков-внедренцев BPMS?

С уважением
Владимир Репин
Оценки: /
17.11.2011 15:22
  от автора
  Дмитрий Пинаев
Проблема обозначена: хочешь автоматизацию - создавай подробные схемы, но при этом они не понятны обычным пользователям. Хочешь, чтобы были понятны? Тогда они не годятся для автомтатизации.
В чем выход?

Автор пишет:
>> Выход видится в разработке методики построения иерархических многоуровневых моделей, где верхний уровень описывает контекст исполнения всего процесса, средний — логику исполнения, а нижний уровень — детали реализации отдельных операций.

Нужно пробовать. Пока есть сомнения. Дело в том, что BPMN не заточен на создание многоуровневых моделей процессов. В нем нужно стараться создавать модель всего процесса на одной диаграмме, т.к. взаимодействие между операциями или процессами может идти достаточно плотное (упомянутая автором детальность описания), вледствие этого и бить на фрагменты может просто не получится.
Оценки: /
20.11.2011 20:37
  от автора
  bell
>> Напомню тезис, что только 6-8% операционных процессов компании нуждаются в автоматизации в BPMS.

Допустим, хотя вряд ли кто-то этот процент замерял. Но только для полноты картины надо добавить, что эти 6-8% составляют критичные для компании процессы; те, от которых буквально зависит ее жизнь и смерть. Это процессы, в которых компания поставила себе целью превзойти всех конкурентов. Оставшиеся 92-94% процентов - это процессы, от которых требуется быть не лучшими, а всего лишь "достаточно хорошими". Соответственно, на первые не жалко потратить силы и время, добиваясь максимально точного их моделирования, а вторые можно себе позволить "по огибающей" нарисовать или описать.

>> Проблема обозначена: хочешь автоматизацию - создавай подробные схемы, но при этом они не понятны обычным пользователям. Хочешь, чтобы были понятны? Тогда они не годятся для автомтатизации. В чем выход?

Проблема такая действительно есть. Выход в том, чтобы начинать с простых моделей, использующих 20% палитры BPMN. Они получаются не сложнее привычных блок-схем, так же интуитивно-понятны и столь же неточны. Согласовав бизнес-процесс на этом уровне, дальше начинаем его детализировать и уточнять - описывать исключения и прочее, о чем пишет Игорь. Хотя диаграмма при этом становится намного сложнее - в ней появляются события и прочие продвинутые элементы BPMN - но благодаря преемственности, сохраняющейся от ранних к последующим версиям, удается добиться того, что бизнес понимает что изображено даже на достаточно продвинутой BPMN-диаграмме. Он не способен ее нарисовать, и от него это и не требуют. Не всегда способен понять без комментариев, увы. Но с пояснениями со стороны аналитика он ее понимает и дает ценные указания по ее доработке. И это не гипотетический сценарий - мы так постоянно работаем.

>>>> Выход видится в разработке методики построения иерархических многоуровневых моделей, где верхний уровень описывает контекст исполнения всего процесса, средний — логику исполнения, а нижний уровень — детали реализации отдельных операций.

Вообще-то это довольно очевидно. Все начинающие аналитики пытаются рисовать BPMN диаграмму в один уровень. Видимо потому, что они привыкли так работать, рисуя блок-схемы или диаграммы EPC. Поэтому выполнение структурной декомпозиция - разбиение процесса на подпроцессы в один или, если понадобится, в несколько уровней,- это один из первых навыков, который прививает Брюс Силвер, на которого ссылается Игорь, да и я на своих курсах.

>> Нужно пробовать. Пока есть сомнения. Дело в том, что BPMN не заточен на создание многоуровневых моделей процессов. В нем нужно стараться создавать модель всего процесса на одной диаграмме, т.к. взаимодействие между операциями или процессами может идти достаточно плотное (упомянутая автором детальность описания), вледствие этого и бить на фрагменты может просто не получится.

Очень странное утверждение. Вы уверены, что говорите именно о BPMN? Потому что к тому BPMN, который знаю я, это не относится. Впрочем если судить по картинкам, которые выдает гугл в ответ на запрос BPMN, то тогда конечно ой [facepalm.jpg]
Оценки: /
25.11.2011 11:39
  от автора
  sagrfi
Владимир пишет:
>> Процесс может быть описан без лишней детализации, минимальными средствами и при этом быть полезным как для анализа и регламентации, так и для автоматизации (не в BPMS, а в других системах).
Соглашусь, не все процессы требуют детального описания. На производстве для одних целей используют эскиз, для других деталировку, а для третьих нужен сборочный чертеж. Но, опытный инженер не называет эскиз деталировкой. Поэтому, предлагаю различать модели с разным уровнем детализации, иначе возникает путаница. Если воспользоваться аналогией из производственной сферы, диаграмма EPC это эскиз, а BPMN – деталировка. В этом нет ничего обидного для EPC и похвального для BPMN. В следующей статье я постараюсь рассказать, как создавать «сборочный чертёж» процесса.

Владимир пишет:
>>Поэтому не соглашусь с тезисом Игоря: "...Диаграмма потоков работ, которую необоснованно называют моделью процесса, не описывает всех деталей поведения процесса и не является процессной диаграммой".
Мы, бизнес аналитики, стали называть моделью процесса любую схему, содержащую квадратики, соединенные стрелочками. Это не правильно. Модель процесса есть совокупность нескольких перспектив (проекций). В отсутствии хотя бы одной перспективы модель описывает не процесс, а только отдельные его аспекты.
Обе нотации EPC и BPMN описывают только поведенческую перспективу, поэтому, следует называть соответствующие модели диаграммами потоков работ. Но если сравнивать ARIS и BPM, мы обнаруживаем, что там присутствуют диаграммы, описывающие отсутствующие перспективы, в обоих случаях говорят об интегрированной модели процесса.

Давайте определимся с терминологией: модель процесса это интегрированное представление нескольких перспектив, диаграмма процесса описывает поведенческую перспективу. Диаграмма процесса может иметь разные уровни детализации.

Владимир пишет:
>> Кто-то наконец предложит нотацию, которая удобна для сотрудников компании, а не только для узкого круга аналитиков-внедренцев BPMS?
Ответ на этот вопрос я пытался дать в статье: давайте договоримся различать эскиз, деталировку и сборочный чертёж, определим, что должны включать соответствующие диаграммы. Для целей документирования будем использовать эскиз, а если потребуется разработка процессной системы, мы доработаем его до деталировки. Иначе нам будут «подсовывать» эскиз со словами «это модель, вы просто не умеете ее читать».
Соглашусь, было бы здорово выполнять эскиз и деталировку в единой нотации.

Дмитрий пишет:
>> Пока есть сомнения. Дело в том, что BPMN не заточен на создание многоуровневых моделей процессов. В нем нужно стараться создавать модель всего процесса на одной диаграмме.
Это действительно сложно. Когда мы создали диаграмму процесса «длинной» в 40 операций, то у нас начались проблемы: модель оказались запутанной, да и с производительностью было плохо (не будем забывать, что модель исполняемая). На то, что бы «разбить» процесс на подпроцессы ушло больше времени, чем на разработку.
Не соглашусь с Дмитрием, BPMN заточен для многоуровневых моделей, это мы не готовы, (см. http://www.bpminstitute.org/articles/article/article/bpms-watch-organizing-complex-bpmn-models.html или на блоге Белайчука).
Нам стало понятно, что разрабатывать снизу-вверх не продуктивно, следует искать метод разработки сверху-вниз, но это тема следующей статьи.

Анатолий пишет:
>>. Выход в том, чтобы начинать с простых моделей, использующих 20% палитры BPMN. Они получаются не сложнее привычных блок-схем, так же интуитивно-понятны и столь же неточны.
Полностью согласен, тем более, что в BPMN 2.0 выделен описательный уровень, палитра которого включает ограниченное подмножество элементов.

Оценки: /
25.11.2011 11:44
  от автора
  Дмитрий Пинаев
>>Оставшиеся 92-94% процентов - это процессы, от которых требуется быть не лучшими, а всего лишь "достаточно хорошими". Соответственно, на первые не жалко потратить силы и время, добиваясь максимально точного их моделирования, а вторые можно себе позволить "по огибающей" нарисовать или описать.

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

Оценки: /
25.11.2011 11:50
  от автора
  Дмитрий Пинаев
>>Согласовав бизнес-процесс на этом уровне, дальше начинаем его детализировать и уточнять - описывать исключения и прочее, о чем пишет Игорь. Хотя диаграмма при этом становится намного сложнее - в ней появляются события и прочие продвинутые элементы BPMN - но благодаря преемственности, сохраняющейся от ранних к последующим версиям, удается добиться того, что бизнес понимает что изображено даже на достаточно продвинутой BPMN-диаграмме. Он не способен ее нарисовать, и от него это и не требуют. Не всегда способен понять без комментариев, увы. Но с пояснениями со стороны аналитика он ее понимает и дает ценные указания по ее доработке.

Мне тоже кажется что это близко к правильному сценарию. Не остается проблемой понимание бизнесом "продвинутой диаграммы". Да, пока рядом стоит объясняющий - руководитель еще может что-то понять. А если взглянет на нее через полгода? А если смотреть будет простой сотрудник в целях понять как ему работать?

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

Выход, к которому прихожу лично я - это иметь два описания в BPMN:
1ое: для целей описания бизнес-процесса для широкого круга пользователей и для регламентации
2ое: создается на основе первого в BPMS системе для целей автоматизации. При этом удаляются незначимые с т.з. BPMS блоки и добавляются нужные элементы.

Оценки: /
25.11.2011 11:59
  от автора
  Дмитрий Пинаев
>>Если воспользоваться аналогией из производственной сферы, диаграмма EPC это эскиз, а BPMN – деталировка. В этом нет ничего обидного для EPC и похвального для BPMN.

Да нет, ситуация совершенно другая. Вспомним зачем создавался BPMN? Это именно служба целям автоматизации. Посмотрите в каких программных продуктах он встречается? 99% это BPMS!

Описание в EPC может быть и гораздо подробнее чем в BPMS (содержать подробный перечень операций исполнителя, например), поэтому называть его эскизом неправильно. А в BPMN много внимания уделяется потокам управления, но при этом мало тому, как исполнителю выполнять процесс. Ведь для автоматизации эти подробности не нужны, в итоге несколько операций схлопываются в одну и получается, что BPMS главное выплюнуть задачу на рабочий стол исполнителя, а как ее выполнять - проблемы исполнителя.
Оценки: /
25.11.2011 12:02
  от автора
  Дмитрий Пинаев
>>Не соглашусь с Дмитрием, BPMN заточен для многоуровневых моделей, это мы не готовы,
Ок, хорошо, если я был не прав.
Оценки: /
25.11.2011 18:04
  от автора
  Репин
"...Описание в EPC может быть и гораздо подробнее чем в BPMS (содержать подробный перечень операций исполнителя, например), поэтому называть его эскизом неправильно. А в BPMN много внимания уделяется потокам управления, но при этом мало тому, как исполнителю выполнять процесс. Ведь для автоматизации эти подробности не нужны, в итоге несколько операций схлопываются в одну и получается, что BPMS главное выплюнуть задачу на рабочий стол исполнителя, а как ее выполнять - проблемы исполнителя...."

- согласен с тезисом Дмитрия.

Далее. За счет элемента нотации "Событие (event) в ARIS eEPC можно разработать более понятную для исполнителя схему, чем в BPMN.

Наверное, не будет секретом такой факт, что специалистам, автоматизирующим деятельность компании не так важны "бизнес-процессы", сколько "системные процессы", т.е. процессы, поддерживаемые системой. То, что вне системы рассматривать "не интересно", т.к. это занимает время, но денег не приносит.

Дополнительные соображения (не по статье Игоря).


В целом, меня беспокоит тот факт, что "управление процессами" рядом специалистов сводится к прорисовке детальных схем в BPMN. Т.е. многоаспектная и сложная задача менеджмента процессов компании сводится к "искусству" проектирования цепочек операций ("технических процессов").
Оценки: /
29.11.2011 04:38
  от автора
  sagrfi
Дмитрий пишет:
>> Выход, к которому прихожу лично я - это иметь два описания в BPMN:
1ое: для целей описания бизнес-процесса для широкого круга пользователей и для регламентации
2ое: создается на основе первого в BPMS системе для целей автоматизации. При этом удаляются незначимые с т.з. BPMS блоки и добавляются нужные элементы.
Абсолютно верно, но это не значит, что должны быть 2 разные модели. Должна быть одна модель, которая на верхнем уровне содержит «минимум» подробностей, а на нижнем все требуемые для исполнения детали (как BPM-щик не могу не напомнить, что BPMN 2.0 включает т.н. descriptive level, который содержит минимум элементов и, т.н., analytical). Но дело, конечно не в нотации. ARIS предлагает дорабатывать EPC диаграммы в BPMN. Хотя это технически возможно, на практике не работает, поскольку аналитики часто допускают просчет в EPC. Я упоминал про смену объекта управления, например, сперва обрабатывается заказ (включающий несколько позиций), затем появляется заявка на производство по каждой позиции отдельно и, наконец, есть грузовая накладная, где разные позиции могут отправляться заказчику или все вместе или по отдельности. В описываемом сценарии основной сквозной процесс может распасться на цепочку взаимодействующих подпроцессов. Для аналитической модели EPC это не страшно, но для исполняемой модели придется капитально переделать процесс. Могут быть и другие сценарии
Утверждаю, проблема не в нотации, а в методологии (хотя сам проектирую в BPMN)

Дмитрий пишет:
>> Описание в EPC может быть и гораздо подробнее чем в BPMS (содержать подробный перечень операций исполнителя, например), поэтому называть его эскизом неправильно. А в BPMN много внимания уделяется потокам управления, но при этом мало тому, как исполнителю выполнять процесс. Ведь для автоматизации эти подробности не нужны, в итоге несколько операций схлопываются в одну и получается, что BPMS главное выплюнуть задачу на рабочий стол исполнителя, а как ее выполнять - проблемы исполнителя.
Дмитрий, если использовать BPMN для аналитического моделирования, то подробности могут остаться вне внимания аналитика, но при разработке исполняемой модели BPMN осуществляется детализация не уровня ОПЕРАЦИЙ, а уровня ЭЛЕМЕНТАРНЫХ ДЕЙСТВИЙ.

Владимир пишет:
Далее. За счет элемента нотации "Событие (event) в ARIS eEPC можно разработать более понятную для исполнителя схему, чем в BPMN.
Событие это самая большая «засада», что это: «событие во времени» или состояние объекта? Если предположить, что это «событие во времени», то можно было бы описать синхронизацию двух ветвей одного процесса. Но, к сожалению, аналитики так не думают, на тех диаграммах, которые я видел, событие отображает состояние объекта после выполнения очередной операции. Тогда чем оно отличается от подписи к стрелке на диаграмме BPMN?
Оценки: /
29.11.2011 17:35
  от автора
  Дмитрий Пинаев
>>Должна быть одна модель, которая на верхнем уровне содержит «минимум» подробностей, а на нижнем все требуемые для исполнения детали (как BPM-щик не могу не напомнить, что BPMN 2.0 включает т.н. descriptive level, который содержит минимум элементов и, т.н., analytical

Вам удавалось создать такую модель для исполнения?

>>но при разработке исполняемой модели BPMN осуществляется детализация не уровня ОПЕРАЦИЙ, а уровня ЭЛЕМЕНТАРНЫХ ДЕЙСТВИЙ.
Сложно поверить, с интересом ждем пример.


Оценки: /
29.11.2011 21:13
  от автора
  Репин
"...Событие это самая большая «засада», что это: «событие во времени» или состояние объекта? Если предположить, что это «событие во времени», то можно было бы описать синхронизацию двух ветвей одного процесса. Но, к сожалению, аналитики так не думают, на тех диаграммах, которые я видел, событие отображает состояние объекта после выполнения очередной операции. Тогда чем оно отличается от подписи к стрелке на диаграмме BPMN? ..."

В чем именно засада? События могу быть разного содержания. Например, может быть таймер "Понедельник, 10-00", а может быть получение информации: "Поступило письмо клиента с подтверждение отгрузки...". Может быть и другое событие: "Товар погружен в вагон"... С точки зрения моделирования "для людей" это вполне понятные события...

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

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

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

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