Описание процесса работы программы

Нотация BPMN стала практически стандартом де-факто для детального описания бизнес-процессов. При всем многообразии элементов этой нотации бизнес-моделирования, ее основные принципы похожи на другие событийно-процессные диаграммы: EPC и UML activity. Именно эти ключевые правила моделирования бизнес-процессов мы и рассмотрим сегодня на практическом примере в рамках обучения начинающих системных и бизнес-аналитиков.

Событийно-процессные нотации бизнес-моделирования: основы диаграмм BPMN, EPC и UML activity

Описать логику выполнения процесса – одна из самых частых задач в профессиональной деятельности системных и бизнес-аналитиков. Она решается с помощью событийно-процессных нотаций моделирования, к которым относятся UML-диаграмма деятельности (UML activity), BPMN (Business Process Model and Notation) и EPC (Event-Process Chain). Хотя построенные по правилам этих нотаций диаграммы немного отличаются внешне, все они по сути представляют собой направленный или ориентированный граф, вершинами которого являются шаги бизнес-процесса, (действия, задачи или функции), а ребрами – стрелки потока управления. Поток управления движется непрерывно от стартовой точки (начало бизнес-процесса) до его окончания (финишной точки), соединяя шаги процесса последовательно или через логические операторы (шлюзы, развилки), не допуская «висячих» вершин. Помимо функций/задач в EPC/BPMN поток управления также соединяет события.

Моделирование бизнес-процессов | Naked BPM

Событийно-процессная диаграмма начинается стартовым событием и заканчивается финишным. Можно сказать, что они ограничивают бизнес-процесс, т.е. определяют его границы (о том, что это такое и зачем это нужно, читайте здесь). В UML activity начало и конец процесса обозначаются черными кругами, в BPMN они могут уточняться типом события (сообщение, таймер и пр.), а в EPC – подробной формулировкой (наступило 1-е число отчетного месяца). Поскольку событие – это уже свершившийся факт, это следует отражать в его названии. Например, «позвонить клиенту» – это НЕ событие, а «сделан звонок клиенту» – это событие.

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)

Код курса

MODP

Ближайшая дата курса

7 августа, 2023

Длительность обучения

8 ак.часов

Стоимость обучения

15 000 руб.

Шаги бизнес-процесса, их участники и артефакты

Процесс состоит из набора шагов (действия в UML activity, функции в EPC и задачи в BPMN), каждый из которых следует представлять в отдельном блоке с названием в виде глагола или отглагольного существительного. Например, «разработка ТЗ» или «разработать ТЗ».

Если в процессе задействованы несколько участников, каждый из которых отвечает за отдельный шаг или выполняет его, это можно показать с помощью дорожек в UML activity и BPMN. На диаграмме EPC для этого следует соединить функцию с организационной единицей или внешним субъектом. Справедливости ради стоит отметить, что дорожки – это не единственный способ показать ответственность за выполнение задач в нотации BPMN – также можно сделать это с помощью групп, объединив несколько задач рамкой с штриховой границей. Подробнее об этом читайте в следующей статье.

Сделал Java программу с интерфейсом / Погодное приложение

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

Немного булевой алгебры: логические операторы и шлюзы

Поскольку диаграммы UML activity, EPC и BPMN позволяют описать логику выполнения бизнес-процесса, в отличие от просто структуры, которую лучше всего показывать в IDEF0, неудивительно что в событийно-процессных нотациях появляются логические операторы. В бизнес-логике их 3: логическое И (AND), логическое ИЛИ (OR) и исключающее ИЛИ (XOR).

Первые два (AND и OR) отражают смысл конъюнкции и дизъюнкции в таблицах истинности, описывающих поведение функций над переменными в булевой алгебре. Чтобы не углубляться в дебри дискретной математики, отметим самое главное свойство логических операторов в контексте описания бизнес-процессов: они позволяют показать ветвления потока управления в зависимости от условий.

Например, если условия коммерческого предложения не подошли клиенту, он может сообщить о желании их изменить ИЛИ отказаться от заключения договора. В этом случае один исход исключает другой, поэтому используется оператор XOR – исключающее ИЛИ. А если один поток не противоречит другому, например, позвонить по телефону или написать письмо, или сделать и то, и другое, подойдет оператор OR. Наконец, если запускаются/сливаются несколько потоков управления, каждый из которых должен дождаться остальных, используется AND.

Примечательно, что в UML activity есть только блок «Решение», эквивалентный исключающему ИЛИ (XOR) и блоки слияния/разделения потоков управления, эквивалентные логическому И (AND), а оператор OR отсутствует. В BPMN и EPC есть все 3 логических оператора, причем в BPMN они различаются по типу (управляемый данными, управляемый событиями и пр.). Причем в UML и EPC следует строго соблюдать правило соединения потоков управления через шлюзы, т.е. в 1 блок задачи/функции входит только 1 стрелка потока управления и выходит тоже только 1. Для слияния и разветвления потоков используются AND, OR, XOR. Обычно оператор, разделивший потоки управления, должен их соединить. Это легко проверить, посчитав на диаграмме количество логических операторов одного типа – оно должно быть четным, если одна из веток не прерывается окончанием процесса.

Как описать бизнес-процесс в BPMN, EPC, UML activity: практический пример

Чтобы показать, как все рассмотренные принципы реализуются в разных событийно-процессных нотациях бизнес-моделирования, рассмотрим в качестве примера процесс заключения договора на обучение на курсах по бизнес-анализу в нашем Учебном центре:

1. Старт процесса начинается с момента, когда клиент оставил заявку на сайте.
2. На основании заявки, где указан курс, даты и другие вопросы, интересующие клиента, менеджер формирует коммерческое предложение и озвучивает его по телефону или направляет на email, или же делает и то и другое – в зависимости от пожеланий клиента и указанных в заявке контактных данных.
3. Узнав подробности коммерческого предложения, клиент принимает решение: будет обучаться или нет по каким-то причинам, например, не подошли условия (время или формат проведения занятий, оплата и пр.). Если клиент не решил обучаться, на этом процесс работы с ним заканчивается.
4. Если клиента устраивают все условия, он сообщает менеджеру о намерении заключить договор об обучении и передает данные для договора.
5. Менеджер формирует проект договора и отправляет его на согласование клиенту.
6. При отсутствии возражений клиент подписывает договор, договор считается заключенным и на этом бизнес-процесс заканчивается и запускает процесс оплаты, описанный на отдельной диаграмме.
7. В случае возражений к проекту договора клиент вносит в него изменения и направляет менеджеру.
8. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, т.е. идет возврат к шагу 5.

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

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

А ограниченный алфавит нотации UML activity обусловливает аскетичный вид следующей диаграммы. Например, из-за отсутствия неисключающего ИЛИ (OR) вместо него пришлось использовать AND, что на самом деле не совсем соответствует реальности. AND предполагает выполнение обоих действий (позвонить и отправить письмо), хотя в действительности может быть достаточно одного из них.

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

Источник: babok-school.ru

Что такое бизнес-процессы и их описание: анализ, схема, модели + примеры

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

Источник: zvonobot.ru

Описание бизнес-процессов: стремление к простоте

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1–4.

Рис. 1. Схема процесса в нотации «Простая » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса.

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

Это скорее операторы принятия решения по условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая » в MS Visio (с движением документов, с использованием блока «Решение»)

1. Наглядное отображение «логики» выбора тех или иных выходов процесса;
2. Акцентирование внимания исполнителя на точку принятия решения/ветвление процесса в зависимости от условий.

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

По мнению автора статьи, рассмотренный на Рис. 1 способ применения блоков «Решение» («ромбиков») является некорректным с точки зрения .

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю.

Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая » в MS Visio (без движения документов, без использования блока «Решение»)

1. Простота и наглядность для исполнителя;
2. На лист можно поместить больше информации, чем в случае формата, использованного на Рис. 1.

1. «Логика» принятия решений скрыта внутри операций процесса;
2. Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса.

В целом, применение схем в формате, подобном представленному на Рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.

На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. , блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам

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

Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

• Существенно сократить количество графических элементов на схеме процесса, и при этом;
• Вывести в регламент процесса необходимую информацию о входящих и исходящих документах.

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

Тот факт, что название стрелки не зависит от документов, которые к ней привязаны, позволяет именовать стрелки на схеме максимально понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию под названием «Сформировать отчет по инкассации за день». (Заметим, что в методологии компании «СТУ» стрелка после операции процесса — это сущность, а не событие. После блока «Решения» можно показывать возможные результаты решения).

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

1. Простота представления;
2. Акцентирование внимания исполнителя на операцию, связанную с принятием решения/ветвлением процесса;
3. На листе А4 может быть представлено большое количество информации.

1. Блок «Решение» не декомпозируется;
2. Неоднозначность в именовании стрелок (возможны разночтения).

В случае применения Business Studio, нотация «Процедура» может быть использована несколько . Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного .

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1–3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

1. При формировании схемы выдерживается строгая, формальная логика процесса;
2. Четко определены все события, возникающие по ходу процесса.

1. Сложность восприятия;
2. Значительная трудоемкость формирования схемы;
3. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем;
4. Информационная избыточность;
5. Занимает слишком много места, что неудобно для документирования.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится — Генеральный директор компании :

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ .

В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной . Ну, а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинги bpmntraining.ru.»

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать

Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

Источник: www.businessstudio.ru