Что такое модель управления делами и нотация (CMMN)

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

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

Вот несколько причин, по которым нам нужен CMMN в дополнение к BPMN:

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

Специальный процесс

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

Вот характеристики Ad-hoc процесса:

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

BPMN против CMMN

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

Управление делами (CM) было представлено ван дер Алстом в 2005 году как инструмент для работников умственного труда. В мае 2014 года OMG опубликовала  стандарт управления делами под названием «Модель управления делами и нотация» (CMMN) . Основное внимание уделяется поддержке непредсказуемых, наукоемких и слабо структурированных процессов. Управление делами — это тип технологии бизнес-процессов, который не использует поток управления для описания процесса.

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

Здесь перечислены различия между BPMN и CMMN:

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

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


Структурированный процесс против дела против специального процесса

Время разработки против времени выполнения

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

Дело имеет две отдельные фазы: время разработки и время выполнения, как описано ниже:

Время разработки

На этапе проектирования бизнес-аналитики участвуют в моделировании, которое включает в себя определение Задач (элементов плана), которые всегда являются частью предопределенных сегментов в модели Кейса, и «дискреционных» Задач, доступных для работника Кейса, которые применяется по выбору на его/ее усмотрение.

Время работы

На этапе выполнения работники Case выполняют план, выполняя Задачи в соответствии с планом и при необходимости добавляя дискреционные Задачи в экземпляр плана Case во время выполнения.

Краткий обзор схемы CMMN

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

  1. Процесс имеет две вехи, которые должны быть достигнуты:
  • Черновик завершен
  • Документ завершен
  1. Некоторые задачи (например  , создание оглавления ) оставлены на усмотрение автора.
  2.  Стадия  «Подготовка черновика » с задачами « Написать текст»  и  «Интеграция графики  » являются обязательными.
  3. На этом этапе определено правило повторения, что символизируется декоратором повторения (т.е.  хэшем ).
  4. В то время как  тема исследования  является обязательной задачей, задача  организации ссылок  должна решаться во время выполнения. Это похоже на  создание графики  и  создание списка рисунков .
  5. Процесс будет завершен, когда  документ будет создан  или  наступит крайний срок .

* Извлечено из модели управления делами OMG и спецификации обозначений

Примечание

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

Основные понятия CMMN

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

Задачи

Задача — это единица работы. Есть три типа задач:

Задачи (дискреционная задача)

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

Слушатели событий

Событие — это то, что происходит в ходе дела. Например, включение, активация и завершение Этапов и Задач или достижение Вех.

Веха

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

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

Стадия и дискреционная стадия

  • Стадию можно рассматривать как «фазу» в кейсе, и обычно она объединяет несколько Задач.
  • Это вместилище элементов, из которых строится план дела и который может развиваться дальше.
  • Стадии могут считаться «эпизодами» Дела. Их можно рассматривать как подпроцессы (аналогично подпроцессам в BPMN), и они также выполняются параллельно.
  • Сцена изображается в виде прямоугольника со скошенными углами и маркером в виде знака «-» в маленьком прямоугольнике внизу в центре («-» обозначает развернутые стадии).
  • Дискреционный этап может быть добавлен «опционально», «специально», в план по усмотрению пользователя.

На рисунке ниже показан расширенный этап с одним подэтапом и тремя задачами.

Критерии

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

  • Одно или несколько триггерных событий (называемых onParts). Это события, которые будут удовлетворять оценке критериев входа или выхода.

Мы можем думать о критериях, формирующих предложение, следующим образом:

([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])

Обратите внимание, что:

  • Где квадратные скобки ([ ]) обозначают необязательные части предложения, а угловые скобки (< >) — замещающие элементы, подлежащие замене.
  • как onPart, так и ifPart являются необязательными  в предложении, но для того, чтобы оно имело смысл, по крайней мере один из них должен присутствовать.

Критерии входа

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

Пример

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

Критерий выхода

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

Дело

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

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

Пример

Таблица планирования

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


34 комментария

  1. Главные новости мира https://ua-vestnik.com и страны: политика, экономика, спорт, культура, технологии. Оперативная информация, аналитика и эксклюзивные материалы для тех, кто следит за событиями в реальном времени.

Leave a Reply

Ваш адрес email не будет опубликован.