Графические нотации моделирования. Моделирование бизнеса — IDEF, UML, ARIS

до EPC

Продолжим наш разговор о Business Studio. Возможности этой системы обеспечивают поддержку полного цикла развития бизнеса: от проектирования архитектуры до поиска путей его улучшения.

Business Studio — это простота и удобство

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

Используемые нотации моделирования

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

1. Нотация IDEF0

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

Методология IDEF0 - это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы. А также — потоки информации и материальных объектов, связывающие эти функции. На рисунке ниже представлена графическая диаграмма в нотации IDEF0 - пример реализован в системе Business Studio.

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

Особенностями нотации являются:

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

Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.

С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».

2. Нотация Процесс (Basic Flowchart B Visio)

Данная нотация Используются графические элементы: событие, процесс, решение, два типа стрелок - стрелки предшествования и стрелки «Поток объектов».

Нотация Процесс поддерживает декомпозицию на подпроцессы.

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

3. Нотация Процедура (Cross-Functional Flowchart B Visio)

Эта нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы - исполнителей действий процесса.

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

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

4. Нотация BPMN 2.0

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Особенность нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, в том, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения.

Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.

В Business Studio представлено 2 типа диаграмм BPMN 2.0 - диаграммы процессов и диаграммы взаимодействия процессов.

Используются следующие графические элементы:

• процессы;
• события;
• шлюзы;

3 типа стрелок:

• поток управления;
• поток сообщений;
• ассоциации;

• документы;
• информация;
• сообщения;базы данных.

Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.

В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, то есть поддерживается декомпозиция.

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

5. Нотация EPC (Event-Driven Process Chain)

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций.

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

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

Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.

А какие нотации используете в своей деятельности Вы?

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

VAD (v alue added chain diagram)

Нотация VAD, предложенная Майклом Портером (Michael Porter) в его работах по корпоративной стратегии, концентрируется на моделировании бизнес-процессов, «создающих ценность» в виде услуг или продукции для потребителя. Модель бизнес-процесса, построенная в нотации VAD, дает общий, не детализированный взгляд на бизнес-процессы.

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

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

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

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

Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio, и многих других инструментах моделирования бизнес-процессов.

Моделирование бизнес-процессов – EPC (event-driven process chain)

Нотация EPC разработана профессором Августом Вильгельмом Шеером в рамках методологии инструментария ARIS. С помощью бизнес-процесс моделируется в виде перечня шагов процесса, запускаемых событиями. Нотация удобна для последующей регламентации бизнес-процесса, а также для анализа информационного потока бизнес-процесса (входящих/исходящих документов).

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

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

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

Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате.

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

Моделирование бизнес — процессов – BPMN (Business Process Model and Notation 2.0)

Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации. Нотация BPMN используется для детального моделирования бизнес-процесса, а количество объектов в данной нотации превышает 100, что позволяет описать все нюансы поведения бизнес-процессов для того, чтобы информационная система могла преобразовать созданную модель в исполняемый код.

Открытость нотации BPMN и поддержка большинством средств моделирования и автоматизации бизнес-процессов сделали данную нотацию лидером в моделировании бизнес-процессов.

В нотации BPMN, помимо шагов бизнес-процесса, можно моделировать стартовые, промежуточные и завершающие события процесса, информационные потоки и потоки сообщений. Из особенностей нотации можно выделить применение по умолчанию стиля моделирования Swim Lane (плавательные дорожки), когда исполнитель показывается вертикальной или горизонтальной полосой, напоминающей дорожки в плавательном бассейне, и именно на этой дорожке располагаются действия/операции, выполняемые данным исполнителем.

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

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

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

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

Моделирование бизнес-процессов — Flow Charting

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

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

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

Нотация Flow Charting не имеет жесткого стандарта, что позволяет моделировать бизнес-процессы с различных точек зрения, добавляя те или иные объекты в модель по необходимости. Этим данная нотация очень похожа на EPC, но имеет еще больше свободы в части применения. Свобода вариантов применения Flow Charting и поддержка большинством недорогих и даже бесплатных средств моделирования бизнес-процессов сделало данную нотацию применимой во множестве компаний.

Из недостатков Flow Charting можно выделить отсутствие типового перечня объектов и атрибутов, что является обратной стороной «свободы» данной нотации. Это позволяет моделировать один и тот же бизнес-процесс в данной нотации так, что модели будут серьёзно отличаться друг от друга.

Несмотря на то, что модели бизнес-процессов в нотации Flow Charting можно встретить достаточно часто, скорее всего она будет уходить в прошлое, уступая место более «строгим нотациям»

Моделирование бизнес — процессов – IDEF (Integrated Definition Language)

Нотация IDEF появилась в 70 ых годах, как стандарт правительства США, фокусирующий внимание на входах, выходах, механизмах и средствах управления бизнес-процессом и увязывающий процессы организации в иерархию. Ключевым элементом данной нотации является функция, тогда как все остальные объекты и взаимодействия моделируются с помощью связей.

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

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

UML (Unified Modeling Languages )

Унифицированный язык моделирования (UML) – это набор нотаций и методов моделирования, предназначенных для описания требований к информационным системам, однако среди нотаций UML есть и специализированная нотация, предназначенная именно для моделирования бизнес-процессов. UML поддерживается Object Management Group (OMG), что сделало данную методологию достаточно распространенной среди ИТ-специалистов.

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

VSM (Value Stream Mapping )

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

Нотация VSM была разработана как часть методологии бережливого производства, и использует набор специфических символов для отображения элементов затрат ресурсов и времени для анализа эффективности бизнес-процесса в проектах Lean 6Sigma. Карта потока создания ценности изображает физическое окружение и потоки материалов и продукции в производстве и используется для того, чтобы привязать к процессу затраты ресурсов и времени, и таким образом дать представление о производительности

Задача данной нотации вовлечь в анализ бизнес-процесса его участников, для того, чтобы стимулировать их к самостоятельному поиску возможностей оптимизации. Как правило модели VSM рисуются в проектах на Flip Chart и не требуют серьёзных средств моделирования бизнес-процессов, ведь на ее основании принимаются решения, а сама модель не становится основой ни для регламента, ни для ИТ-решения.

Основное при создании модели в нотации VSM это заполнение временных атрибутов по процессу, для поиска «бутылочных горлышек» и мест излишнего хранения запасов.

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

SIPOC

Аббревиатура SIPOC означает: Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель). Это шаблон документирования процессов, принятый в методологии Шесть сигм, фактически это даже не нотация модели, а формат таблицы, который позволяет описать бизнес-процесс на верхнем уровне. Модель SIPOC наиболее эффективно применять при определении границ бизнес-процесса, взаимодействующих сторон и входов/выходов процесса.

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

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

Моделирование бизнес-процессов – выводы

Итак, я рассмотрел некоторые нотации моделирования бизнес-процессов, которые можно встретить на российском рынке (более подробно они описаны в главе BPM CBOK , посвященной моделированию бизнес-процессов). Какую из нотаций выбрать для использования – это вопрос открытый, например, для моделирования бизнес-процессов организации на верхнем уровне я использую нотацию VAD, для первичного моделирования бизнес-процесса, выбранного для оптимизации, проще использовать SIPOC или VAD. Для создания детальных моделей бизнес-процессов – упрощённый BPMN для моделирования кросс-функционального взаимодействия или EPC для детального моделирования с целью формализовать информационный поток и множество объектов, связанных с бизнес-процессом. Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе, то тут уже не обойтись без нотации BPMN.

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

Ещё раз об IDEF0

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

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

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

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

BPMN – новый взгляд на процессы

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

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

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

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

FlowChart – назад к основам

На самом деле нотации с таким названием не существует, имеется множество вариаций на тему обычной блок-схемы, например, Basic FlowChart, Сross Functional Flowchart и т.д.. Все эти нотации позволяют описывать потоки работ и распределять ответственность за выполняемые функции внутри процесса. Множество программных продуктов используют разновидности этих нотаций для описания процессов нижнего уровня в дополнение к описанию процессов верхнего уровня при помощи IDEF0.

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

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

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

eEPC – мы пойдём своим путём

Авторами нотации eEPC является известная немецкая фирма IDS Scheer AG. Как и нотации на базе FlowChart, eEPC предназначена для описания процессов нижнего уровня, вот только в основе неё лежат не функции персонала, а события, которые в свою очередь уже инициируют выполнение какого-либо действия со стороны персонала. Из-за данной особенности стандартные процессы получаются почти в два раза больше по сравнению с их аналогами, описанными в нотации FlowChart.

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

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

Разумеется, данная заметка не презентует на полноту изложения и не раскрывает особенности использования каждой нотации в отдельности, зато надеюсь, что после прочтения данной статьи, вопросов в стиле «Что нам выбрать BPMN или IDEF0? » станет меньше.

BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.

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

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

Как максимум, позволяет впоследствии провести автоматизацию бизнес-процессов в соответствии с имеющейся схемой.

История возникновения BPMN

Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.

Основные графические элементы BPMN

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

Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.

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

• Пул и Дорожки
• Действия
• Шлюзы или Развилки
• События
• Потоки
• Артефакты

В BPMN 2.0 элементы представлены в виде специальных значков. Создатели данной системы стремились к тому, чтобы набор значков был исчерпывающим и обеспечивал возможность наглядного отображения максимального разнообразия схем бизнес-процессов. В итоге значков очень много и с полным списком можно ознакомиться в документации по BPMN, которая переведена на русский язык членами Ассоциации BPM-профессионалов России. Здесь мы остановимся только на базовых элементах, без которых не обойдётся ни одна схема бизнес-процесса. Этого достаточно для общего знакомства с BPMN и понимания основных принципов нотации.

BPMN элементы “Пул” и “Дорожка”

Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.

Например, пулом окажется весь набор действий по погрузке товара и отправке его клиенту.

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

BPMN элемент “Действие”

Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).

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

• Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
• Циклическое действие выполняется многократно, пока заданное условие верно.

BPMN предполагает следующие графические отображения для основных типов действий:

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

Здесь стоит отметить, что современные BPM-системы зачастую предлагают более широкий набор типов действий, чем предлагает BPMN. Например, в инструменте для моделирования бизнес-процессов в Comindware Business Application Platform вы найдёте графические элементы для нескольких типов элементарных действий, а также встроенных кейсов:

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

BPMN элементы “Развилка” или “Шлюз”

Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.

BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:

	Шлюз исключающего «или»	Используется для создания альтернативных потоков процесса или сходящихся потоков управления.
	Параллельный шлюз	Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса.

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

Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:

• Этап 7. Звонок клиенту с целью оценить качество обслуживания.
• 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
• 2. Если клиент недоволен, выяснение причины.

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

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

BPMN элемент “Событие”

“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.

Графические элементы событий в BPMN классифицируют двумя способами:

1. В зависимости от положения события на схеме процесса:

	Начальное событие (инициирующее бизнес-процесс)
	Промежуточное событие
	Конечное событие (заканчивающее бизнес-процесс).

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

1. По типу события классификация следующая:

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

Очень часто начальные и конечные события являются событиями-сообщениями.

BPMN элементы “Потоки”

Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.

	Поток управления	На стандартный поток управления не воздействуют условия и он не проходит через шлюзы, т.е. является неконтролируемым.
	Условный поток управления	Используется для того, чтобы показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только в том случае, если выполнятся заданное условие. Ромбик у основания стрелки добавляется, если условный поток управления является исходящим от процесса. Ромбик не добавляется, если условный поток управления является исходящим от шлюза.
	Поток управления по умолчанию	Используется тогда, когда необходимо показать, что дальнейшее выполнение процесса будет происходить по определённому потоку только если не выполняется ни одно из заданных условий.
	Поток сообщений	Используется для отображения межпроцессного взаимодействия – отображает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку.
	Ассоциация	Применяется для визуализации связи между элементами потока и объектами, не являющимися элементами потока (артефактами).

BPMN элементы “Артефакт”

Под артефактами в BPMN понимают объекты, которые не влияют на исполнение бизнес-процесса напрямую. Это могут быть документы, данные, информация.

Основные виды артефактов:

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

Преимущества BPMN

BPMN-описание бизнес процесса имеет несколько преимуществ.

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

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

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

Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.

Бесплатный BPMN инструмент

Cawemo - это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.

Бесплатный BPMN инструмент

Обзор

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

Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.

BPMN Примеры

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

Сценарий моделированияo

Предположим, мы хотим моделировать процесс в BPMN, и процесс вызывает некоторые бизнес-правила. Мы будем использовать пример создания счета. Чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.

Это очень простой пример, который покажет нам, где применять BPMN, а где нет.

Роли двигателя Создать счет Запрос счета Вычислить скидку Создать счет Счет создан

Объяснение

Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат - очень простой процесс.

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

Поэтому имеет смысл разделить процессы и бизнес-правила.

Создать счет Сделать 2% скидку добавить 1% скидки Кто покупатель? Запрос счета Сумма заявки? Тип покупателя? Создать счет Счет создан Сделать 3% скидку Сделать 4% скидку Кто покупатель? добавить 1% скидки добавить 1% скидки 1000 - 1500 500 - 999 >2000 < 500 Тип A Тип A Тип A обычный обычный обычный

Зависимые экземпляры

Сценарий моделирования

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

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

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

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

Решение с сигнальным событием

Creditworthiness Check Посмотреть запросы Посмотреть запущеные события (с ними) запуск экземпляров одного и того же клиента? и того же клиента? Првоерить кредит Проверка выполнена Проверка выполнена Запись в базуданных нет да

Объяснение

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

Решение с событием Message

Проверка кредитоспособности Проверить запросы Проверить запущенные процессы тот же клиент) запущенные экземпляры одного клиента? проверить кредит кредит подтвержден ожидать события покупателя? проверить на ожидание случаев (из тот же клиент) запуск экземпляра завершен проинформировать ожидание экземпляра База Данных База Данных нет нет да да

Объяснение

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

Решение с таймером и циклом

Creditworthiness Check Проверить запросы проверить запущенные процессы (одного пользователя) запущенные экземпляры одного клиента? perform credit check подождать немного времени проверить кредит База Данных нет да

Объяснение

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

Принцип четырех глаз

Сценарий моделирования

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

Случаи использования

Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:

• Утверждение оплаты
• Утверждение счета
• Утверждение контракта

Решение как диаграмма BPMN 2.0

1й согласователь Согласование запрошено Оценить запрос прочитать и прокомментировать Задача завершена Процеесы в двигателе Подтвердить запрос подтвердить или согласовать (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Объяснение

Мы используем отдельные пулы для Process Engine, для первого утверждающего и для второго утверждающего. Таким образом, мы можем четко определить, кто контролирует какой процесс.

В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.

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

Сам список задач не моделируется, чтобы уменьшить сложность.

Вариации

Утверждение в качестве сбитых пулов

1й согласователь 2й согласователь Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден нет да да нет

Определение приемника с помощью LDAP

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена LDAP Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден determine 1st and 2nd approver 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Ежемесячное выставление счетов

Сценарий моделирования

В этом примере объясняется очень распространенная борьба со структурированием диаграмм BPMN 2.0. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обращаться за юридической консультацией, когда им это нужно. Адвокат предоставляет запрошенный совет и ставит оплачиваемые часы на лист времени клиента. Когда месяц закончился, бухгалтер-юрист определяет оплачиваемые часы на основе расписания и создает счет-фактуру.

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

Решение как диаграмма BPMN 2.0

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время Запрос отработал Счетчик клиента Клиент Учет месячного дохода 1й день в месяце Определить оплачиваемые часы создать и отправить счет получить деньги Счет исполнен 14 дней Отправить напоминание Только один в месяц Несколько за месяц

Объяснение

Наиболее важным аспектом диаграммы является ее структура.

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

Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными - листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.

Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.

Неправильный способ моделирования

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время 1 в следующем месяце определить оплачиваемые часы создать и отправить счет Получить деньги Счет исполнен 14 дней Отправить напоминание Клиент

Объяснение, почему это неправильно

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

Дополнительная информация, необходимая после задачи пользователя

Сценарий моделирования

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

Решение 1. Запросить информацию от другого пользователя

Пользоваель зашел Пользоваель зашел Движок процесса Задание для пользователя Нужна доп. информация? Запрос информации (от пользователя) ... нет да

Решение 2. Запросить информацию у технической службы

Пользоваель зашел Some Technical Service Движок процесса Задание для пользователя Нужна доп. информация? Отправить запрос Информация получена... нет да

Обработка партии заказов с рынка

Ситуация

Мы хотим моделировать следующий сценарий с использованием BPMN 2.0: предположим, что компания получает заказы от разных каналов распространения. Один из этих каналов - это рынок. В определенные промежутки времени заказы с рынка принимаются в виде партии. Каждый заказ в этой партии должен быть проверен перед ввозом в систему ERP.

Решение как диаграмма BPMN 2.0

ERP Система Рынок Импортирова заказы в ERP Каждые 10 минут Собрать все заказы с рынка Процесс заказа Новый одиночный заказ Проверить данные заказа данные корректны? Импорт заказа в ERP систему Один заказ в процессе Дата заказа некорректна Все заказы в процессе отдельные Заказ нет да

Объяснение

В этом примере показан очень общий сценарий моделирования. Иногда мы называем это проблемой 1-к-n. Один экземпляр процесса (Import of Orders) приводит к множеству отдельных экземпляров процесса другого процесса (ERP-системы). Типичными конструкциями являются несколько экземпляров или циклов, которые запускают другие процессы, используя сообщения (потоки сообщений).

Переназначение пользовательских задач

Сценарий моделирования

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

Решение 1: Услуга передачи сообщений и переназначение

Заметка

Это имеет смысл, если движок вызывает службу для определения нового правопреемника.

Решение 2: Правила передачи сообщений и правила переназначения

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

Заметка

Это имеет смысл, если движок вызывает механизм правил для определения нового правопреемника.

Решение 3. Событие границы сообщения и неявное переназначение

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

Заметка

Это имеет смысл, если движок определяет самого нового цессионария, например, используя выражение.

Двухэтапная эскалация

Сценарий моделирования

Мы будем использовать следующий пример, чтобы проиллюстрировать, как моделировать двухэтапную эскалацию с использованием BPMN 2.0. Когда мы хотим пиццу, мы заказываем ее. Иногда доставка пиццы поднимается, и доставка занимает больше 20 минут. Затем мы жалуемся на службу доставки. После этого мы даем им еще 30 минут, чтобы доставить пиццу. Если они не сделают это своевременно, мы откажемся и отменим наш заказ.

Решение 1. Два шлюза на основе событий

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Пицца съедена 30 минут Жаловаться в сервис доставки Пицца доставлен 20 минут Заказ отменен Заказ отменен

Преимущества этого решения

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

Недостатки этого решения

Шлюз, основанный на событиях, не является интуитивным символом BPMN стандарта BPMN, необходим опыт.

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

Решение 2: Принять задание с включенными таймерами

Пицца разыскивается Заказать пиццу Есть пиццу Пицца съедена Жаловаться в сервис доставки Заказ отменен Заказ отменен Ждать пиццу Жаловаться на заказ 50 минут 30 минут

Преимущества этого решения

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

Недостатки этого решения

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

То, как работает прерывающий и не прерывающий таймер, требует глубокого понимания приложенных событий.

Решение 3. Один шлюз на основе событий с общим таймером

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Съесть пиццу Время вышло! Жаловаться на доставку Заказ отменен Заказ отменен Выполнено задание? Таймер показал больше да нет

Преимущества этого решения

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

Недостатки этого решения

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

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

BPMN Modeling Styles

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

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

Приведенные ниже примеры иллюстрируют проблему абстрактным примером.

Хороший пример обработки потоков

Процесс запущен выполнить первуюу задачу Обязательное действие? выполнить задачу два Процесс завершен выполнять задачу три ok? да План A План B нет

Встречный пример

Процесс запущен Задание первое Обязательное действие? perform task two Процесс завершен Задание третье Ок? да План A План Б нет

Самое главное: каждый символ BPMN должен иметь ярлык.

События должны быть помечены с использованием причастия «объект + прошлое». Начальные события всегда должны маркироваться указанием триггера процесса. Конечные события должны быть помечены конечным состоянием процесса.

Сам процесс (пул) также должен всегда маркироваться. Этот ярлык должен указывать имя процесса и роль, которая его выполняет.

Задачи должны быть помечены с помощью объекта + глагол. Это заставляет модельного человека сосредоточиться на том, что действительно сделано во время задания.

Шлюзы X-OR должны быть помечены вопросом. Потоки исходящей последовательности должны быть помечены возможными ответами на эти вопросы (условия).

Хороший пример наименования

Проверить дату заказаa Сервис Заказа Заказ получен Проверить заказ Проверить заказ Дата заказа корректна Дата заказа корректна? Дата заказа некорректна да нет

Общая версия

Имя процесса Роль, выполняющая процесс Триггер oпроцесса Объект + глагол Объект + Причастие Первое конечное состояние после окончания процесса Вопросы? Второе конечное состояние после окончания процесса ответ 1 ответ 2

Пример счетчика

Заказ сделан Старт Проверить Записать статус в БД Конец Ошибка Ок

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

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

Хороший пример симметричной модели

Готовить салат Появился голод Выбрать рецепт Какое блюдо? Готовить макароны Есть еду Голод утален Готовить стейк Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат Теплая еда

Встречный пример

Готовить салат Голод появился Выбрать рецепт Какое блюдо? Готовить макароны Съесть еду Голод утален приготовить стейкk Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат теплая еда

Хороший пример симметричной модели 2

Свежий товар Заказ доставлен использован старый товар Сумма заказа более 25.000 €? Процесс заказа Организовать доставку Package goods Доставить заказ Процесс заказа да нет

Встречный пример 2

Свежая продукция Закад доставлен старый товар на складе Сумма заказа больше 25.000 €? Заказать Сделать доставку Товар Доставка заказаr Процесс заказа да нет

Причина проста. Люди склонны интерпретировать размеры задач, хотя они не имеют семантики в стандарте BPMN.

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

Некоторые считают, что большие задачи занимают больше времени, чем меньшие задачи - по данным BPMN это неверно.

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

Хороший пример равных размеров задач

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена

Встречный пример

1й согласователь Подтвердите запрос Сделан запрос документ и комментарий удалены задача завершена