Опубликовано вBPMN

Модернизация доставки пиццы: всестороннее руководство по применению BPMN 2.0

Введение: Цифровая трансформация классической отрасли

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

В этом исследовании рассматривается, какПиццерия, гипотетическая, но типичная компания в сфере общественного питания, используетМодель и нотация бизнес-процессов (BPMN) 2.0для моделирования и модернизации своего процесса выполнения заказов «от начала до конца». Через детальное рассмотрение реального сценария — обработки как стандартных, так и исключительных потоков заказов — в этой статье показано, как BPMN выступает мощным инструментом для визуализации, анализа и оптимизации бизнес-процессов.

Разбирая процесс«Заказ пиццы»мы раскроем основные и продвинутые концепции BPMN, продемонстрируем лучшие практики проектирования процессов и покажем, как цифровое моделирование может способствовать достижению операционного превосходства в сфере услуг.

1. Краткое резюме: почему BPMN важен в сфере общественного питания

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

Результатом стало моделирование полного жизненного цикла заказа пиццы — от онлайн-размещения до доставки или отказа — с учетом:

  • Динамическое принятие решений на основе наличия инвентаря и производственной мощности.

  • Внешнее взаимодействие с поставщиками и участниками торгов.

  • Планы на случай сбоев в цепочке поставок.

  • Четкая передача данных и определение ответственности за процесс.

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

2. Обзор диаграммы: совместный процесс в действии

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

Ключевые участники процесса

Участник Роль Тип взаимодействия
Пиццерия Владелец процесса и внутренний участник Контролирует основной рабочий процесс; выполняет задачи и принимает решения.
Клиент Внешний заинтересованный сторон Инициирует процесс через онлайн-заказ; получает обновления о доставке.
Поставщик теста/сыра Внешний поставщик Отвечает на запросы закупок с помощью потоков сообщений.
Участники торгов Внешние участники рынка Соревнуются на торгах за специальные ингредиенты.

📌 Примечание: Хотя пулы и ленты подразумеваются заголовками задач и потоками сообщений, диаграмма использует потоки сообщений для явного определения границ между организациями — что подчёркивает сильные стороны BPMN в моделировании межорганизационного взаимодействия.

Основная бизнес-цель

Эффективно выполнить заказ пиццы клиента или грациозно обработать отказ при отсутствии ресурсов.

Эта двойная цель подчёркивает важность устойчивости и адаптивности—ключевых тем в современном проектировании процессов.

3. Основные концепции BPMN, проиллюстрированные

BPMN 2.0 предоставляет стандартизированный визуальный язык для моделирования бизнес-процессов. Диаграмма заказа пиццы иллюстрирует его ключевые компоненты.

A. Объекты потока: Скелет процесса

1. События: Триггеры и результаты

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

  • Событие начала (зелёный круг): Начать запрос на заказ
    → Запускается при получении сообщения Заказ пиццы (онлайн) от клиента. Это обозначает официальное начало процесса.

  • Событие окончания (красный/толстый круг): Заказ завершён
    → Финальное состояние, достигаемое независимо от успеха или неудачи. Это гарантирует, что каждый путь процесса завершается корректно.

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

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

2. Действия: выполняемая работа

Действия представляют единицы работы — либо атомарные задачи, либо сложные подпроцессы.

  • Задачи (скруглённые прямоугольники):

    • Сделать заказ пиццы

    • Получить подтверждение заказа

    • Доставить пиццу

    • Отказ в заказе (нет ингредиентов)

  • Подпроцессы (скруглённые прямоугольники с символом «+»):

    • Закупка теста / сыра (поставщик)
      → Внутренний подпроцесс, в котором магазин выступает покупателем по отношению к своему поставщику.

    • Аукцион специальных ингредиентов (участник аукциона)
      → Сложный подпроцесс, имитирующий механизм конкурентных торгов для редких или премиальных ингредиентов.

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

3. Шлюзы: Точки принятия решений, формирующие поток

Шлюзы контролируютрасхождение и схождение потоков. В этой моделиИсключительные шлюзы (XOR)используются исключительно — при каждом решении выбирается только один путь.

  • Решение 1: Ингредиенты/Свободная емкость доступны?
    → Определяет, продолжать ли выполнение собственными силами или начинать закупку.

  • Решение 2: Стандартные детали доступны?
    → Оценивает, может ли поставщик удовлетворить базовые потребности в ингредиентах.

  • Решение 3: Все специальные ингредиенты выиграны?
    → Финальная проверка после аукциона: удалось ли магазину получить все необходимые специальные товары?

⚠️ Наилучшая практика: Каждый шлюз XOR должен иметьчеткие, взаимоисключающие метки (например, «Да» / «Нет»). Неоднозначность приводит к путанице и ошибкам моделирования.

B. Соединяющие объекты: нервная система процесса

1. Последовательный поток (сплошная линия с стрелкой)

  • Определяетвнутренний порядок выполнения в рамках одного процесса.

  • Соединяет события, действия и шлюзыв пределах домена пиццерии.

2. Поток сообщений (пунктирная линия с открытой стрелкой)

  • Представляетвнешнее взаимодействиечерез границы организаций.

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

Ключевые потоки сообщений на диаграмме:

  • Заказ пиццы (онлайн) → Начать запрос на заказ (Начало сообщения)

  • Покупка теста / сыра → Поставщик (Отправляет запрос)

  • Аукцион специальных ингредиентов (участник аукциона) → Участник(и) аукциона (Отправляет уведомление об аукционе)

  • Доставить пиццу → Неявно отправляет обновление для Клиент

✅ Правило thumb: Используйте последовательный поток для внутренних шагов; поток сообщений для внешних взаимодействий. Никогда не смешивайте их.

C. Объекты данных: информационная основа

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

  • Оболочки (например, Заказ принят, Запрос детали, Предложения по..., Победа/Поражение в предложении) изображают структуры или состояния данных.

  • Соединены через ассоциации данных (тонкие штриховые линии) для обозначения зависимостей ввода/вывода.

Пример:

  • Задача Получить подтверждение заказа требует ввода: Заказ принят

  • Подпроцесс Приобретение теста / сыра потребляет Запрос детали и производит Ответ поставщика

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

D. Участники процесса: кто участвует?

Хотя пулы и ленты не полностью нарисованы, потоки сообщений и метки задач четко определяют роли участников.

Участник Роль в процессе
Пиццерия Центральный координатор; выполняет задачи, принимает решения, управляет подпроцессами.
Клиент Инициирует процесс; получает уведомление о доставке или отказе.
Поставщик Поставляет стандартные ингредиенты (тесто, сыр); отвечает на запросы на закупку.
Биддер(ы) Участвуют в аукционах за специальные ингредиенты; получают уведомления о ставках и результаты.

🔄 Инсайт по сотрудничеству: Диаграмма демонстрирует совместный BPMN, где магазин взаимодействует с внешними сущностями через хорошо определенные обмены сообщениями — отражая реальные паттерны интеграции.

4. Глубокий анализ: поток процесса заказа пиццы

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

Фаза 1: Инициация заказа и сортировка

  1. Начальное событие: Запрос на начало заказа запущено по Заказ пиццы (онлайн) сообщение от клиента.

  2. Задача: Сделать заказ пиццы – Магазин фиксирует детали заказа (тип пиццы, начинка, адрес доставки).

  3. Решение: Ингредиенты/вместимость доступны?
    → Это первый критический перекресток в процессе.

Фаза 2A: Путь успеха — наличие в наличии

Когда ингредиенты и вместимость кухни достаточны:

  1. Путь «Да»: Перейти к выполнению.

  2. Задача: Получить подтверждение заказа
    → Входные данные: Заказ принят (зависимость данных подтверждена).

  3. Задача: Доставить пиццу – Кухня готовит пиццу, команда доставки отправляется.

  4. Событие окончания: Заказ завершен – Жизненный цикл заказа успешно завершается.

✅ Результат: Клиент получает свою пиццу вовремя. Внешние зависимости не требуются.

Фаза 2B: Путь внешнего закупа – ограничения по мощности

Когда магазин работает на полной мощности или не хватает ключевых ингредиентов:

  1. Путь «Нет»: Запускается внешняя закупка.

  2. Подпроцесс: Закупка теста / сыра (поставщик)
    → Отправляет сообщение внешнему поставщику.

  3. Решение: Стандартные компоненты доступны?

Подпуть 2B.1: Успех через поставщика

  • Путь «Да»: Поставщик подтверждает наличие.

  • Событие связи: A - Статус заказа A (выбрасывание)
    → Поток переходит к событию перехвата в верхней части диаграммы.

  • Продолжение: Процесс возобновляется на Получить подтверждение заказа → Доставить пиццу → Заказ завершён.

🎯 Результат: Закупка прошла успешно. Поток бесшовно интегрируется обратно в основной процесс.

Подпуть 2B.2: Ошибка → Инициация аукциона

  • Путь «Нет»: Поставщик не может выполнить запрос.

  • Подпроцесс: Аукцион специальных ингредиентов (участник аукциона)
    → Магазин проводит или участвует в аукционе по премиальным ингредиентам (например, импортный моцарелла, трюфельное масло).

  • Потоки сообщений:

    • Аукцион специальных ингредиентов → Участник(и) аукциона (отправить уведомление об аукционе)

    • Участник(и) аукциона → Аукцион специальных ингредиентов (отправить ставки)

  • Финальное решение: Все специальные ингредиенты выиграны?

Результат А: Успех аукциона («Да»)

  • Все необходимые ингредиенты получены.

  • Событие связи: A - Статус заказа A (бросок) → переходит к событию перехвата вверху.

  • Поток возобновляется в Получить подтверждение заказа → Доставить пиццу → Заказ завершён.

Исход B: Неудача аукциона («Нет»)

  • Не все специальные ингредиенты получены.

  • Переход потока к: Отказ в заказе (нет ингредиентов)

  • Финальная задача: Отказ в заказе – Система генерирует сообщение для клиента.

  • Событие окончания: Заказ завершён – Даже при неудаче жизненный цикл заказа завершается.

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

5. Лучшие практики и руководящие принципы проектирования BPMN

На основе модели заказа пиццы, вот шесть основных рекомендаций для проектирования надёжных, поддерживаемых процессов BPMN:

Рекомендация Объяснение Почему это важно
1. Обеспечьте поток от начала до конца Каждый процесс должен иметь чёткое начало и хотя бы одно событие завершения. Предотвращает бесконечные циклы и ошибки моделирования.
2. Маркируйте все исходы шлюза XOR Всегда маркируйте пути как «Да» и «Нет» (или осмысленные альтернативы). Устраняет неоднозначность и поддерживает автоматизированную валидацию.
3. Используйте последовательный поток внутри, сообщения — снаружи Никогда не смешивайте их. Последовательный поток = внутренний; поток сообщений = между границами. Сохраняет ясность и устанавливает организационные границы.
4. Используйте подпроцессы для сложности Разбивайте сложные рабочие процессы (например, аукционы, утверждения) на подпроцессы. Сохраняет основные диаграммы читаемыми и модульными.
5. Используйте промежуточные события-ссылки Используйте А-типа события-ссылки для перехода между удалёнными точками. Снижает визуальную загруженность и улучшает масштабируемость диаграммы.
6. Визуализируйте зависимости данных Показывайте входные/выходные данные с помощью конвертов и связей данных. Уточняет предварительные условия и позволяет проводить интеграционное тестирование.

✅ Совет профессионала: Используйте инструменты моделирования BPMN (например, Camunda, Bizagi, Signavio), чтобы автоматически проверять эти правила. Многие инструменты выявляют отсутствующие конечные события, необозначенные шлюзы или неверные типы потоков.

6. Стратегические последствия: за пределами диаграммы

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

Операционные преимущества

  • Быстрое принятие решений: Четкие точки принятия решений позволяют оперативно реагировать.

  • Устойчивость цепочки поставок: Механизм аукциона обеспечивает резервный вариант при отказе поставщиков.

  • Масштабируемость: Подпроцессы можно повторно использовать в разных линейках продуктов (например, бургеры, десерты).

Факторы цифровой трансформации

  • Готовность к интеграции: Потоки сообщений напрямую соответствуют API, вебхукам или системам EDI.

  • Возможности автоматизации: Задачи, такие как Получение подтверждения заказа можно автоматизировать с помощью движков рабочих процессов.

  • Аналитика и мониторинг: Каждый путь можно отслеживать, что позволяет формировать KPI, такие как коэффициент выполнения заказов, время закупки и причины отказа.

Гарантирование устойчивости процесса в будущем

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

  • Внедрите компенсацию: В случае неудачной доставки запустить процесс возврата средств.

  • Поддержка нескольких каналов: Расширьте модель для включения заказов по телефону, через приложение и в магазине.

7. Инструменты: использование Visual Paradigm для превосходного моделирования по стандарту BPMN 2.0

Этот белый документ, основанный на Выполнение заказа пиццы исследовании (Рисунок 1), рассматривает, как инструменты корпоративного моделирования — в частности Visual Paradigm—превосходят простые инструменты рисования (например, MS Visio), обеспечивая превосходство моделирования, семантическую точность и сотрудничество, необходимые стандарту моделирования и нотации бизнес-процессов (BPMN 2.0).

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

1. Введение: Необходимость профессиональных инструментов моделирования по BPMN

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

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

2. Обеспечение целостности процесса: семантическая валидация на практике

Одной из самых больших сложностей при моделировании процесса заказа пиццы является его сложность, включающая внутренние потоки, внешнее сотрудничество, промежуточные события связи («A») и подпроцессы. Visual Paradigm предоставляет активные защитные механизмы.

Вывод из исследования: правильное использование типов потоков

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

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

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

Проверка начальных/конечных точек и ветвей принятия решений

Профессиональные инструменты активно обеспечивают соблюдение семантики BPMN:

  • Проверка логики принятия решений: Когда размещается шлюз XOR (например, Стандартные детали доступны?), Visual Paradigm заставляет моделировщика пометить альтернативные исходящие пути («Да» и «Нет»). Статический инструмент может позволить покинуть шлюз без меток на исходящих путях, что создаст неопределенность при выполнении.

  • Обеспечение конечного состояния: Каждый путь процесса должен приводить к конечному событию. Инструмент может выполнить отчет проверки, который гарантирует, что ни одна активность не является «тупиком» или частью бесконечного цикла. Модель заказа пиццы правильно проходит от Начать запрос на заказ к Заказ завершен по всем путям.

3. Расширенное управление моделированием: подпроцессы и ссылка «A»

Сложность диаграммы заказа пиццы в значительной степени зависит от продвинутых концепций, таких как Подпроцессы (обозначены знаком + плюс) и События промежуточных связей (круги со стрелками, помеченными «A»). Профессиональные инструменты необходимы для управления этими иерархиями.

Иерархия и декомпозиция

  • Сценарий: Покупка теста/сыра и Аукцион специальных ингредиентов представлены как высокоуровневые свернутые подпроцессы на изображении image_1.png. Они скрывают значительную сложность (например, правила ставок и логику оценки нескольких поставщиков).

  • Преимущество профессиональных инструментов: В Visual Paradigm это не просто изображения. Вы можете «Пройти глубже» или дважды щелкните по + знаку, чтобы открыть новую, связанную диаграмму которая детализирует внутреннюю логику этого этапа закупок. Такая иерархическая связь сохраняет читаемость основной диаграммы, размещая необходимые детали в другом месте.

  • Повторное использование: Подпроцесс Auction Special Ingredients может быть сохранён как воспроизводимый компонент в репозитории инструмента. Его можно использовать в разных бизнес-процессах (например, закупка нового оборудования), не перерисовывая его.

Связанность событий связи

  • Сценарий: Процесс использует три события «выброса связи» (обозначены как «A») в различных точках успеха/неудачи, которые все «перепрыгивают» к соответствующему событию «поймать связь» (обозначено как «A») рядом с началом.

  • Преимущество профессиональных инструментов: Visual Paradigm гарантирует, что события связи структурно сопоставлены. У вас не может быть события «выброса» «A» без соответствующего события «поймать» «A». Инструмент также может навигировать или «отслеживать» соединение, позволяя аналитикам мгновенно переходить между связанными разделами во время обзора.

4. Документирование, совместная работа и отслеживаемость

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

Интегрированное документирование и метаданные

Хотя image_1.png предоставляет четкие метки действий, реальная реализация требует глубоких деталей.

  • Интеграция метаданных: Когда вы выбираете действие, такое как Auction Special Ingredients в Visual Paradigm вам предоставляется подробная панель свойств. Здесь аналитики могут документировать:

    • Ответственный за процесс: Кто отвечает за аукцион?

    • КПЭ: Каковы ожидаемые циклы времени?

    • Риски: Что произойдет, если не будет получено ни одной заявки?

    • Структура данных: Какова фактическая схема данных для Заявки на специальное тесто/сыр потока сообщений?

  • Результат: Все документы хранятся с элементом модели, что предотвращает создание отдельного, несвязанного набора спецификаций в MS Word. Отчеты затем могут автоматически генерироваться из этой метаданных.

Общий репозиторий процессов и командная работа

  • Совместная работа: Visual Paradigm позволяет нескольким членам команды одновременно работать над одной и той же моделью через централизованный репозиторий (облачный или локальный). Можно управлять версиями и отслеживать изменения, что критически важно, когда процесс выполнения обновляется заинтересованными сторонами из операционной, закупочной и ИТ-сфер.

5. Выполнение модели и отслеживаемость требований

Ключевое преимущество использования сложного инструментария — это интеграция с последующей инженерной разработкой.

Согласование BPMN с ИТ

  • BPMN XML: Основным выходным файлом профессионального инструментария не является .png файл; это стандартный BPMN 2.0 XML. Этот файл XML может быть напрямую импортирован в ведущие системы управления бизнес-процессами (BPMS) и исполнительные среды (например, Camunda, Appian).

  • Разработка, управляемая процессом: Команда ИТ использует диаграмму заказа пиццы как начальный спецификации разработки. Им не нужно расшифровывать требования из ручного документа. Они видят точно, где находятся автоматизированные решения (Ингредиенты/Доступная мощность?) и где происходят взаимодействия с людьми.

Следуемость требований

  • Следуемость:Visual Paradigm позволяет моделистам связывать элементы BPMN с основополагающими требованиями (например, «Требование удовлетворенности клиента» для времени доставки 30 минут может быть явно связано с элементом Доставить пиццу активностью). Если требование изменится, влияние на модель процесса можно будет мгновенно визуализировать.

Модель выполнения заказа на пиццу (Рисунок 1) служит идеальным тестовым примером для профессиональных инструментов. Это доказывает, что всестороннее моделирование процессов — это больше, чем эстетическое упражнение. Профессиональные платформы, такие как Visual Paradigm выступают в качестве необходимых партнеров в достижении превосходства в моделировании, превращая диаграммы из пассивных визуализаций в точные, исполняемые и ценные бизнес-активы. Инвестирование в правильные инструменты — это не добровольные расходы, а фундаментальное требование для любой организации, серьезно настроенной на автоматизацию процессов и цифровую трансформацию.

Заключение: BPMN как катализатор операционного превосходства

Тот Заказ пиццы кейс-стади демонстрирует, что даже похожий на простой бизнес-процесс может получить пользу от строгого моделирования с использованием BPMN 2.0. Применяя основные принципы — четкие события, логические ворота, структурированные потоки и явные зависимости данных — пиццерия превращает хаос в ясность.

Более чем просто диаграмма, эта модель становится:

  • А обучающим инструментом для новых сотрудников.

  • А коммуникационной основой между ИТ, операциями и поставщиками.

  • А основой для автоматизации и непрерывного улучшения.

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

🍕 Заключительная мысль:
Так же, как идеальная пицца требует правильного сочетания ингредиентов, идеальный процесс требует правильного баланса структуры, ясности и адаптивности. BPMN обеспечивает этот баланс — по одному потоку за раз.

Приложение: Краткая справка — Символы BPMN 2.0

Символ Название Значение
🟢 Круг Событие начала Процесс начинается
🔴 Круг Событие окончания Процесс заканчивается
🟡 Круг с стрелкой Промежуточное событие связи Маркер перехода для обеспечения непрерывности потока
📝 Округлённый прямоугольник Задача Одна рабочая операция
📦 Округлённый прямоугольник с «+» Подпроцесс Сложный внутренний рабочий процесс
⚖️ Диамант Шлюз Точка принятия решения
➝ Сплошная линия Последовательный поток Внутренний порядок выполнения
➜ Пунктирная линия Поток сообщений Внешняя коммуникация
📥/📤 Конверт Объект данных Входные/выходные данные
🧩 Бассейн/полоса (подразумевается) Участник Организационная роль