Шаблоны корпоративных бизнес-процессов позволяют быстро и эффективно настроить форму бизнес-процесса согласно потребностям пользователя. При создании бизнес-процесса на основе шаблона происходит не только изменение внешнего вида бизнес-процесса, но и первоначальное заполнение его данными. Для работы с шаблонами бизнес-процессов используется специальный справочник «Шаблоны корпоративных процессов». Экранные формы данного справочника созданы с учетом всех возможностей управляемых форм платформы «1С:Предприятие 8.3 / 8.2 ».

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

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

Форма шаблона бизнес-процесса содержит несколько закладок.

• На закладке «Маршрут бизнес-процесса» содержится список сотрудников который будет скопирован в список исполнителей создаваемого бизнес-процесса. В списке маршрута может использоваться как прямая адресация с указанием конкретных исполнителей, так и ролевая адресация с указанием роли и объектов адресации.
• Закладка «Наименование реквизитов» содержит наименования реквизитов для формы бизнес-процесса.

В шаблоне бизнес-процесса определяются следующие названия реквизитов:

• Наименование кнопки «Старт»
• Наименование группы исполнителей
• Наименование группы документов
• Наименование текста процесса

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

Закладка «Параметры процесса» содержит перечень параметров.

Указанные параметры устанавливаются при создании нового корпоративного бизнес-процесса на основании данного шаблона. Шаблон бизнес-процесса также содержит ссылку на требуемый результат, а также поле текста процесса. Данные параметры копируются в создаваемый, на основе шаблона, корпоративный бизнес-процесса.

Важно! В шаблоне корпоративного бизнес-процесса можно указать вид маршрута: а) список исполнителей или б) единственный исполнитель.
В случае выбора варианта «Единственный исполнитель» форма шаблона бизнес-процесса изменяется и становится доступной закладка «Исполнитель».

На закладке «Исполнитель» можно указать исполнителя с использованием ролевой или прямой адресации. При создании корпоративного бизнес-процесса на основании шаблона, в котором указан вид маршрута «Единственный исполнитель» форма бизнес-процесса также изменяется.

В корпоративном бизнес-процессе вместо списка исполнителей появляется поле для указания единственного исполнителя. Пример приведен на рисунке выше.

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

Механизм бизнес-процессов (МБП) появился в составе "1C:Предприятие" в начале 2005 г., и можно утверждать, что это - очень перспективное и полезное новшество платформы. Его суть - автоматизация цепочек связанных операций, направленных на достижение общей цели, обычно в контексте организационной структуры, определяющей функциональные роли и связи. Автоматизация бизнес-процессов позволяет повысить качество организации работы и эффективность управления.

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

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

Основные сведения о механизме бизнес-процессов в 1С

Бизнес-процессы в "1С:Предприятие" нужны для того, чтобы объединять отдельные операции (выписка счета, прием наличной оплаты, отпуск товара со склада и т. д.) в цепочки взаимосвязанных действий, приводящих к достижению конкретной цели (например, продажа товара за наличный расчет). Участие сотрудников в жизненном цикле бизнес-процесса достигается ролевой маршрутизацией.

Механизм бизнес-процессов в 1С обеспечивается сразу несколькими объектами конфигурирования: бизнес-процессы, задачи, регистр сведений и параметр сессии. Как правило, типы реквизитов адресации задачи и измерений регистра сведений назначаются ссылками на соответствующие справочники, поэтому к четырем вышеперечисленным видам добавляются еще справочники.

Основные объекты механизма бизнес-процессов - это бизнес-процессы и задачи. Они используют друг друга и еще три вспомогательных объекта - параметр сеанса, регистр сведений и справочники. Вспомогательные объекты не используют ни друг друга, ни основные объекты.

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

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

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

Операции, выполняемые в ходе бизнес-процесса, представлены на карте маршрута точками действий, которые содержат информацию о том, кто и что должен сделать на данном этапе. Исполнитель может определяться персонально (Иванов) или с учетом ролевой маршрутизации («Кладовщик», "Руководитель отдела продаж"). При переходе бизнес-процесса на точку действия он автоматически формирует задачи, устанавливая в них предусмотренные реквизиты адресации. После того как исполнитель отметит задачу как выполненную, бизнес-процесс автоматически переходит к следующей точке маршрута в соответствии с картой.

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

Механизм бизнес-процесса в 1С допускает несколько видов маршрутизации.

• Жесткая. Бизнес-процесс имеет карту, не содержащую условных и параллельных переходов с жестко определенными адресатами для каждой точки маршрута. Отклонение таких бизнес-процессов не допускается.
• Свободная. Адресаты точки карты маршрута бизнес-процесса не установлены и определяются программно или интерактивно в течение жизненного цикла бизнес-процесса.
• Условная. Карта маршрута предусматривает проверку условий и переход по соответствующим ветвям. Переходы могут быть как бинарными (условие), так и множественными (выбор варианта)
• Параллельная. Карта маршрута предусматривает разделение бизнес-процесса на параллельные ветви с возможностью последующего слияния (ожидания). Продвижение бизнес-процесса по каждой из параллельных ветвей происходит независимо, по мере выполнения соответствующих задач.

Как правило, в реальных картах бизнес-процессов встречаются все эти типы маршрутизации.

Общая схема создания бизнес-процесса в 1С

1. Создаем регистр адресации

• a. Создаем формы

2. Создаем задачу

• a. Заполняем вкладку адресация
• b. Данные заполняем реквизитами передаваемыми между задачами и самим бизнес-процессом
• c. Создаем формы

3. Создаем бизнес-процесс

• a. Заполняем задачу, реквизиты, создаем формы
• b. Рисуем карту маршрута

Особенности адресации

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

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

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

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

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

При указанных правилах адресации Иванов будет назначен исполнителем задач по "Мир" либо при указанном контактном лице "Директор", либо если контактное лицо указано не будет. По работе с контактным лицом "Кладовщик" исполнителем будет назначен "Петров".

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

Возможности применения Механизма бизнес-процессов.

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

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

Таким образом, речь идет еще об одном ключевом направлении развития прикладных решений "1С:Предприятия" - повышении уровня их управляемости. Применение механизма бизнес-процесса дает возможность собирать качественно иную информацию о работе системы управления предприятием, на основе которой руководители могут проводить объективный анализ эффективности функционирования как организации в целом, так и отдельных ее сотрудников. Этот механизм позволяет перенести акцент с учетных задач на управление бизнесом в целом.

Подробнее познакомиться с механизмом бизнес-процессов, реализованным в "1С:Предприятии 8", разработчики и пользователи могут с помощью демонстрационной конфигурации, распространяемой на диске "Информационно-технологическое сопровождение" (ИТС). Там представлены несколько простых бизнес-процессов ("Продажа товара", "Поручение" и "Согласование" и др.), которые показывают различные варианты практического применения этого механизма.

На заметку программисту.

Порядок выполнения обработчиков бизнес-процесса

1. Форма: перед выполнением
2. Форма: перед записью (сначала на клиенте, затем на сервере)
3. Модуль задачи: перед выполнением
4. Бизнес-процесс: перед выполнением
5. Модуль задачи: при выполнении
6. Модуль задачи: перед записью
7. Модуль задачи: при записи
8. Бизнес-процесс: при выполнении
9. Форма: после записи (сначала на сервере, затем на клиенте)

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

New Page 2

Изучаем 1С 8.3. Урок 31. Бизнес процессы. Продолжение.

Чтобы смотреть урок полностью, подпишитесь на .

В платном разделе статья находится .

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

Проверим:

А теперь рассмотрим такой механизм бизнес процесса, как адресация. Для этого нам необходимо создать регистр ...

аналогично, в справочник подразделений введем СлужбаБезопасности, а в должности Менеджер. Теперь идем в карту бизнес процесса и устанавливаем адресацию. Для задачи "Прием заявки" ставим должность "Менеджер":

Длязадачи "Рассмотрение заявки" устанавливаем подразделение СлужбаБезопасности: ...

Заводим новый бизнес процесс, он начинается с задачи "Прием заявок":

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

Создадим другой бизнес процесс и до ведем его до состояния рассмотрения заявки:

Эту задачу будут видеть только те, кто сопоставлен в регистре адресации с подразделением "Служба безопасности", в нашем случае Петров:

Но в общей форме задач, в той, которая не по исполнителю, будут видны по прежнему все задачи:

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

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

На сегодня пока все, а на следующем уроке мы займемся второй веткой нашего бизнес процесса, которая пока у нас еще не реализована.

Когда я столкнулся с бизнес-процессами, они показались мне таким же темным лесом, как в своё время регистры расчета. Я пустыми глазами смотрел на демо-пример от 1С, читал статьи в Интернете, и ничего не понимал.

Однако в бизнес-процессах нет ничего сложного. Это своё кристально чистое видение я попытаюсь передать и вам.

Уясните сразу, что бизнес-процессы - это всего лишь два новых объекта в 1С 80: бизнес-процессы и задачи. Причем задачи можно использовать самостоятельно и без знания бизнес-процессов. Их можно трактовать, как список задач для текущего пользователя.

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

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

Бизнес-процесс может находиться в одной или сразу нескольких точках (при параллельном выполнении).

Пользователь создает новый бизнес-процесс, и запускает его. Как только бизнес-процесс доходит до блока выполнения, он создает новую задачу, и адресует его тому исполнителю, который прописан в этом блоке выполнения. Как только исполнитель выполняет задачу, бизнес-процесс идет дальше по блок-схеме. Условия вычисляются программно на языке 1С (анализируются реквизиты бизнес-процесса). Вот и вся нехитрая механика.

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

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

Можно назначить задачу целому подразделению и она будет показана у всех пользователей подразделения.

Как соотносятся задачи и бизнес-процессы? Одному виду бизнес процесса соответствует один вид задачи, один вид задач может использоваться в нескольких бизнес процессах. Это странно, потому что в различных точках исполнения одного бизнес процесса мы можем ожидать разные задачи. Например, задача согласования может отличаться от задачи ввода первичных документов. Логичнее было бы привязывать разные задачи к одному бизнес-процессу. В демо-примере все сделано на одном виде задач. Если мы все же хотим использовать разные виды задач, можно использовать вложенные бизнес процессы.

Как видите, все очень просто.

Несколько советов «чайникам» :

· Посмотрите в режиме «Конфигуратор » демо-базу по бизнес-процессам с ИТС - познавательно. В режиме «Предприятие» можете не смотреть, особо ничего не поймете.

· У бизнес-процесс нужно обязательно указать вид задачи - без него конфигурация не сохранится. Сначала может использовать один вид задачи для всех бизнес-процессов.

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

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

· У задачи нужно не только заполнить реквизиты адресации, но и выбрать основной реквизит адресации, например «Пользователь», выбрать регистр сведений для адресации, переменную сеанса, которая будет соотноситься с основным реквизитом адресации и иметь с ним один тип (!).

· Также не забудьте указать соотношения между реквизитами адресации задачи и измерениями регистра адресации, чтобы связь между задачей и регистром сведений заработала.

· Для контроля списка задач, адресованных текущему пользователю, можете использовать консоль отчетов по таблице всех задач «Задачи» и виртуальной таблице задач текущего (или указанного) пользователя «ЗадачаЗадачиПоИсполнителю ».

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

С чего начать

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

Алгоритм примерно такой:

0: Начало

А: Выполнение: Менеджер оформляет расходную накладную.

Б: Выполнение: Руководитель отдела утверждает накладную.

В: Условие: Если накладная утверждена, тогда Г иначе Д.

Г: Выполнение: Кладовщик выполняет отгрузку. Переход на Е.

Д: Конец: Завершение бизнес-процесса в статусе «Отмена».

Е: Конец: Нормальное завершение бизнес-процесса.

Флажок «Утверждена» можно вносить или в расходную накладную или в сам бизнес-процесс, как реквизит.

Что нужно проконтролировать :

· Когда вы запускаете бизнес-процесс, создаются задачи.

· Когда вы выполняете задачи, бизнес-процесс продвигается по карте маршрута (для этого нужно в форму бизнес-процесса вывести карту маршрута).

· Задачи появляются только у тех пользователей, которым они адресованы (вот здесь мне пришлось попотеть).

В официальной документации по платформе 1С:Предприятие 8.2 в разделе «13.7. Разделение и слияние » поведение бизнес-процесса в точках разделения и слияния описано так:

«Для разделения бизнес-процесса на несколько параллельно (одновременно и независимо) исполняемых ветвей используется точка разделения. Точка разделения имеет один вход и неограниченное количество выходов.

Для синхронизации разделенных ранее ветвей используется точка слияния. Бизнес-процесс не будет выполняться дальше точки слияния, пока все входящие в нее ветви не будут пройдены.»

Продемонстрирую это на примере простой карты маршрута (рис.1)

В точке разделения создаются задачи в каждой из ветвей (рис.2), далее каждая ветвь выполняется параллельно, а задача в точке Действие4 будет создана тогда, когда будут выполнены все задачи каждой ветви (рис.3)

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

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

Процедура Действие3ПриСозданииЗадач (ТочкаМаршрутаБизнесПроцесса , ФормируемыеЗадачи , Отказ )

Для каждого ЗадачаОбъект Из ФормируемыеЗадачи Цикл

ЗадачаОбъект . ВыполнитьЗадачу ();

КонецЦикла;

КонецПроцедуры

Такой обработчик приведет к тому, что создаваемая задача сразу будет выполнена. Стартуем новый бизнес-процесс с картой маршрута, приведенной на рис.1. И что мы увидим? После выполнения задачи Действие3 была создана задача Действие4 (рис.5), несмотря на то, что другие ветви процесса еще не выполнены! Тех, кто попытается воспроизвести указанную ситуацию, предупреждаю: у вас вместо написания обработчика для точки Действие3 может оказаться необходимым написать обработчик автовыполнения задачи для точки Действие1 или Действие2. Точка действия, автовыполнение которой "ломает" схему процесса - это именно та точка, в которой создается первая задача после точки разделения. От чего зависит последовательность создания задач, будет рассмотрено ниже.

Такого поведения простой схемы маршрута никак нельзя предположить, исходя из приведенного в начале статьи описания. Может это какая-то ошибка отображения схемы? Нет, на самом деле все так и происходит. Бизнес-процесс не только выполняется дальше точки слияния, не ожидая завершения задач в параллельных ветвях, но и создает повторно задачи в точках маршрута, следующих за точкой слияния после завершения параллельных ветвей. Смотрим список задач по нашему процессу и видим по 2 задачи для точек Действие4 и Действие5 (рис.8)

О чем это говорит? Фактически это означает, что при автоматическом выполнении задачи Действие3 мы получим поведение бизнес-процесса, соответствующее схеме, приведенной на рисунке 9, то есть точка слияния при выполнении одной ветви пропускается. Но это тоже не всегда верно. Если в точке Действие4 мы не будем выполнять первую из созданных задач, до появления второй задачи в результате выполнения параллельных ветвей до точки слияния, то следующая задача в точке Действие5 будет создана только при выполнении обеих задач в точке Действие4 , то есть бизнес-процесс как бы исправляет допущенную ранее ошибку игнорирования точки слияния. Далее по схеме маршрута будет создаваться только по одной задаче. Тем, кого заинтересовало такое поведение бизнес-процесса, предлагаю убедиться в этом самостоятельно.

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

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

Проверяем работу бизнес-процесса со вложенным процессом и убеждаемся в аналогичном поведении. На рисунке 12 - схема бизнес-процесса после старта.

Всегда ли проявляется такое поведение в подобных схемах? Давайте разберемся. Обратим внимание на то, что задачи в точке разделения создаются в том порядке, в каком были добавлены линии в точке разделения. Это можно увидеть, если вывести имена соединительных линий (рис.13).

Попробуем поменять местами Линия2 и Линия4. И наконец-то при старте нового процесса мы видим ожидаемый результат (рис.14)

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

Делаем вывод:

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

Эту зависимость следует учитывать и при доработке существующих схем. Допустим, мы решили, что вместо одной задачи в точке Действие1 на рисунке 14, которая у нас начала работать так, как требуется, должен быть вложенный процесс, который при определенных условиях, может выполниться автоматически по условию аналогично рисунку 10. Тогда при старте нашего процесса мы увидим знакомую картину с игнорированием точки слияния (рис.15)

В заключение отмечу, что указанное поведение бизнес-процессов было замечено еще на платформе 8.1 и продолжает проявляться на последних релизах 8.2. При подготовке статьи тестирование выполнялось на релизе платформы 8.2.15.310.