Кейс: Оптимизация процесса голосования по электронной почте рабочей группы BPMN. Контекст и вызовы

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

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

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

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

3. Застой процесса: Когда не удавалось достичь консенсуса или участия, процесс иногда застывал, что требовало ручного вмешательства председателя рабочей группы для возобновления или сброса обсуждения.

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

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

Решение по BPMN

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

Детальный анализ процесса

Процесс инициируется событием начала: Выявлены вопросы. Затем поток структурируется в четыре ключевых этапа, которые соответствуют пронумерованным циклам на диаграмме.

1. Этап 1: Цикл обсуждения (подпроцесс)

   • Роль: Менеджер списка вопросов.

   • Деятельность: Менеджер инициирует обсуждение, модерируя электронные письма и проводя конференц-вызовы. Это критически важно для сложных тем, где простое голосование «за»/«против» недостаточно.

   • Механизм цикла: В конце этого подпроцесса менеджер выполняет задачу «Оценить ход обсуждения (менеджер списка вопросов)». Эта задача устанавливает переменнуюDiscussionOver == TRUE или ЛОЖЬ.

   • Устойчивость: Если обсуждение считается незавершенным или возникают новые вопросы, процесс возвращается к началу действия «Среднее обсуждение по электронной почте». Это предотвращает преждевременный переход процесса к голосованию до того, как вопрос будет созревшим.

2. Этап 2: Цикл предупреждения участия

   • Роль: Менеджер списка вопросов и члены рабочей группы.

   • Деятельность: Как только обсуждение завершено, менеджер инициирует голосование, выполняя задачу «Объявить вопросы для голосования».

   • Механизм цикла: Процесс затем ожидает голосования членов. Критически важным шагом является шлюз «Достаточно ли членов проголосовали?» (>= 86%)”. Это требует высокого кворума (86%), чтобы обеспечить достоверный результат.

   • Устойчивость (система предупреждений): Если кворум не достигнут («НЕТ»), процесс следует определённому исключительному пути.

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

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

     • Этот поток возвращается к задаче «Объявить вопросы для голосования». Критически важно, этот цикл может произойти толькоодин раз. В пуле участников отображается задача «Пересмотреть обязательство», за которой следует шлюз. Это гарантирует, что если участник не проголосует,послеполучив предупреждение,то его голос будет зафиксирован как воздержание в следующем цикле, что предотвращает бесконечные циклы предупреждений. Этот цикл является ключевой особенностью, обеспечивающей подотчетность.

3. Этап 3: Многокруговой цикл голосования

   • Роль: Менеджер списка вопросов и члены рабочей группы.

   • Деятельность: Если кворум достигнут, голоса собираются и подсчитываются в рамках «Подпроцесса сбора голосов».

   • Механизм цикла: После подсчета голосов, шлюз «Вопросы без большинства?» проверяет, достигли ли предложения необходимой поддержки.

   • Устойчивость (уточнение выбора): Если вопрос не получил большинства, процесс переходит в цикл уточнения. В пуле менеджера отображается задача «Проанализировать уточненные варианты» (часто на основе обратной связи по первоначальному голосованию), а члены просят «Подать пересмотренный голос». Это позволяет группе сократить количество вариантов (например,например,с пяти вариантов до двух лучших) и проголосовать повторно, а не просто провалить вопрос. Этот цикл разработан для решения сложных вопросов предпочтений без необходимости перезапуска всей дискуссии.

4. Этап 4: Перезапуск цикла обсуждения

   • Роль: Менеджер списка вопросов.

   • Деятельность: Это окончательный путь исключения для непримиримых вопросов.

   • Механизм цикла: После того как цикл «Голосование в несколько этапов» исчерпан, шлюз «Не прошел два цикла голосования?»» проверяет, не удалось ли достичь согласия по вопросу после двух полных циклов голосования.

   • Устойчивость (полный сброс): Если ответ «ДА», поток процесса сбрасывается, а не завершается. Поток сообщений соединяет этот шлюз с началом подпроцесса «1». Подпроцесс «Цикл обсуждения». Это заставляет группу вернуться к началу, переосмыслить проблему, и начать фазу обсуждения заново с новым контекстом. Это предотвращает завершение процесса в состоянии «непрорешано» и обеспечивает четкий, документированный путь для повышения.

      

     

Подробное объяснение процесса электронного голосования по BPMN

Представленная диаграмма BPMN представляет структурированный совместный рабочий процесс, предназначенный для решения вопросов в рабочей группе BPMN. Модель определяется как сотрудничество между двумя основными участниками, или «пулами»: «Менеджер списка вопросов и «Члены рабочей группы.

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

1. Внутренний цикл обсуждения

Процесс начинается с подпроцесса «Цикл обсуждения», который является основной деятельностью по управлению новыми вопросами.

• Механизм: В рамках этого подпроцесса менеджер списка вопросов выполняет задачу «Оценка прогресса обсуждения».

• Логика: Эта задача обновляетОбсуждение завершено переменную либо в TRUE, либо в FALSE.

• Действие цикла: Если переменная установлена в FALSE, подпроцесс запускает цикл, требуя повторения всего цикла модерации электронной почты и конференц-вызовов до тех пор, пока обсуждение не будет признано завершённым.

2. Цикл предупреждения о участии

Этот цикл служит защитой от низкой явки избирателей в конце этапа голосования.

• Механизм: Процесс достигает точки принятия решения, задающей вопрос: «Достаточно ли членов проголосовали?». Для одобрения требуется двухтрети большинства голосующих членов.

• Действие цикла: Если ответ НЕТ, система проверяет, получали ли члены уже предупреждение. Если нет, процесс возвращается к задаче «Объявить вопросы для голосования», чтобы инициировать второй цикл голосования с прикреплённым предупреждением.

3. Цикл многоэтапного голосования

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

• Механизм: Если после первого голосования остаются «Вопросы без большинства?», подпроцесс выполняется для сужения возможных решений до двух наиболее популярных вариантов.

• Действие цикла: Затем избирателям предлагается изменить свои голоса на основе уточнённых вариантов, и поток возвращается к подпроцессу «Собрать голоса» для второго, более сфокусированного раунда.

4. Перезапуск цикла обсуждения

Это последний, окончательный цикл, когда процесс голосования не даёт результата после нескольких попыток.

• Механизм: Если цикл многоэтапного голосования исчерпан без достижения успешного консенсуса, процесс проверяет, произошло ли два неудачных цикла голосования.

• Действие цикла: Вместо завершения процесс полностью сбрасывается, возвращаясь к начальному подпроцессу «Цикл обсуждения» для повторного запуска этапа обсуждения.

Обзор ключевых концепций BPMN, использованных в процессе

• Объединения сотрудничества: Диаграмма разделяет ответственность между Менеджер списка вопросов (кто координирует процесс) и Члены рабочей группы (кто участвует в обсуждениях и голосовании).

• Синхронизация: Модель использует эти четыре цикла для синхронизации деятельности по параллельным путям, таких как таймеры, модерация электронной почты и конференц-вызовы, обеспечивая, чтобы менеджер имел четкое представление о состоянии вопроса.

• Устойчивость: Используя эти циклы, процесс справляется со «непривычными» бизнес-сценариями, когда консенсус может быть трудно достижимым или участие недостаточным, предотвращая застой процесса в незавершённом состоянии.

Заключение

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

Встраивая эти циклы непосредственно в определение процесса, группа достигла:

• Увеличение участия: Цикл автоматических предупреждений обеспечивает, что кворум редко пропускается.

• Более высокое качество решений: Цикл голосования в несколько этапов позволяет решать сложные, многоальтернативные вопросы.

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

• Прозрачность и аудитоспособность: Каждое действие, от отправки предупреждения до сброса цикла, является частью формальной модели процесса, обеспечивая чёткую аудиторскую следующую за всеми решениями.

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