Case Management Model and Notation. Снова про внедорожник для бизнес-процессов

Максим Смирнов, как всегда, компетентно и грамотно изложил свое мнение в связи с выходом первой версии  Case Management Model and Notation 

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

Вероятно, та же закономерность лежит и в основе того, что любители управления бизнес-процессами скептически относятся ко всему, что связано с темой adaptive case management (Впрочем, верно и обратное утверждение). Как того и следовало ожидать, появившийся в мае этого года OMG стандарт Case Management Model and Notation, вызвал в сообществе BPM определенное недоумение. Зачем нужен стандарт на кейс-менеджмент? Разве кейс-менеджмент это не то же самое, что и agile – делаем все что хотим и будь что будет? Постараюсь немного развеять это заблуждение.

Во-первых, Case Management Model and Notation (CMMN) это не только и не столько про графическую нотацию. Двадцать страниц из восьмидесяти, действительно, посвящены графической нотации, но спишем это на традиционную любовь OMG к изобразительному искусству.  Большая часть стандарта не про нотацию, а про модель. Что, впрочем, банально следует из названия. В этом документе описывается модель предметной области кейс-менеджмент. Довольно понятно и просто в документе описано, что такое кейс, что такое кейс-файл, какие элементы в нем могут быть, что такое таблица планирования кейса, какого рода задачи могут встречаться в ходе обработки кейса и пр. Для любителей картинок приведены UML диаграммы. В общем, предметная область определена. Теперь не надо спорить является ли тот или иной инструмент системой кейс-менеджмента (об этом тоже написано, см. 2.5).

Во-вторых, достаточно четко определена целевая аудитория стандарта. Ожидаемыми пользователями являются бизнес-аналитики (раздел 4.2). Предполагается, что они будут использовать инструменты кейс-менеджмента для выявления повторяемых задач, событий и вех, создавать для них формальные шаблоны и включать их в кейс-модель. Проще говоря, речь идет о едином цикле исполнения и улучшения процесса, описанном Робом Ингландом в книжке Plus! The Standard + Case approach Кстати, надеюсь, что данная тема будет интересна для участников российского отделения IIBA, т.к. представляет одну из новейших практик деятельности бизнес-аналитика. Я же постараюсь всячески способствовать продвижению этой практики.

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

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

Источник: http://mxsmirnov.wordpress.com/author/mxsmirnov/

Комментарии Вадима Ипатова, заместителя генерального директора Компании "ИнтерТраст" по развитию бизнеса:

Концепция АСМ выросла из BPM в попытке избавиться от родовых проблем последнего. Но до сих пор нет единого представления о том, что же представляет собой АСМ и не прекращаются споры на тему ACM vs BPM. Статья, написанная в 2011 году, не потеряла актуальности до сих пор. Каким должно быть соотношение методологии и технологий? Как теории управления соотносятся с реалиями жизни? диалектика с простым житейским опытом? Обсуждение этих вопросов и в самой статье и особенно в комментариях.

Ни в коем случае не отрицая ценности BPM, мы все же в нашей CompanyMedia пошли пока по пути разделения сервисов BPM и ACM. Пусть жизнь покажет, будут ли они сходиться или иметь каждый свои области применения. Очень заманчивой видится перспектива, когда изначально к решению какой-то задачи применяется инструментарий АСМ, а затем, после нескольких итераций принимается решение, похожа ли данная задача на процесс. Тогда подключается бизнес аналитик для описания процесса и разработки регламентов. Трудно спорить с тем, что когда в процессе участвуют разные службы (когда он кросс-функциональный), то лучше, когда руководители служб договариваются «на берегу» (согласовывают регламент). Договариваться в ходе исполнения процесса сложнее. Но что для бизнеса выгоднее – представление процесса в виде шаблона кейса или регламента – наверное, определяется характером задачи.

Перейти к разделу "Строим  открыто"