Case management и модели процессов

Продолжаем читать статью Хенка де Мана «Case Management: A Review of Modeling Approaches»

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

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

Моделирование деятельности такого рода требует от нас более глубоко изучения к подходам по моделированию бизнес процессов. Из литературы Хенк выбрал три подхода к моделированию процессов:

  • Activity-based
  • Artifact-based
  • Communication-based

Первый подход знаком нам по BPMN и BPEL и характеризуются четко отсортированной последовательностью задач. При использовании третьего подхода цель процесса достигается в результате серии взаимодействий между участниками. А вот второй подход достаточно интересен. Он лежит в основе множества специализированный ИТ-решениях, однако в должной степени не стандартизирован.
В основе artifact-based подхода лежит понятие бизнес-объекта. Наиболее частым примером бизнес-объекта является “заказ” (это может быть заявка на приобретение товаров в интернет-магазине, заказ на предоставление услуги и т.п.) . Бизнес-объект обладает множеством различных свойств, таких как уникальный идентификатор, дата создания, результат проверки кредитной истории, ожидаемая дата поставки и т.п., а так же набором состояний: «новый», «ожидает проверки», «выполнен».

Case managment претендует на объединение всех трех изложенных подходов. Задача, безусловно, амбициозная, но… вполне реализуемая. По крайней мере, такие модные фишки как архитектурный стиль REST и семантический web направлены на универсализацию представлений объектов и отношений между ними.

Одним словом, чем дальше, тем интереснее

Ключевые моменты Case Management

По статье Хенка де Мана Case Management: A Review of Modeling Approaches

Хенк де Ман, research director компании Corsys, выделил следующие особенности case management (далее CM):
1. Центральное место в управлении кейсами занимает непосредственно кейс. Так в здравоохранении, из которого проистекает направление СМ, «история болезни» пациента накапливает всю необходимую информацию и определяет дальнейшие действия терапевта.
2. CM предполагает сотрудничество и коммуникацию. Кроме того, участникам обработки кейса придется реагировать на новые события
3. Как правило, действия сотрудников обслуживающих кейс, строго не предопределены. Эксперту понятно, что необходимо сделать в текущей ситуации, а дальнейшие действия вытекают из результатов первого шага.
4. Цель является более ясной, чем путь её достижения. Для достижения цели возможны различные пути. Выбор того или иного конкретного пути будет определяться в ходе достижения цели, а не планироваться заранее.
5. Исполнитель кейса – это эксперт (knowledge worker), владеющий навыками, которые позволяют ему иметь определенную свободу в принятии решения, в рамках зоны своей ответственности.

Что интересно в этих характеристиках. Во-первых, произнеся слова сотрудничество, коммуникация, сбор информации и knowledge worker мы моментально попадаем на территорию социального ПО, т.е. для корпораций – область Enterprise 2.0. Во-вторых, мы не расстаемся с такими понятиями как роли, активности, последовательность действий и пр., т.е. продолжаем пребывать на территории BPM. Одним словом, нас ожидает микс наиболее узнаваемых ИТ идей текущего момента social software и BPM

Продолжение: Case management и модели процессов

Case management: недостающее звено проектного управления

Управление бизнес-процессами(BPM) и управление проектами, вроде бы, расположены на разных полюсах видов деятельности современного предприятия. Но в действительности, сходства между ними существенно больше, чем это видится на первый взгляд. В обоих случаях нам предстоит выстроить цепочку скоординированных действий различных участников для достижения совместного результата. Потому и проблемы у проектного и процессного управления довольно схожие. И, пожалуй, главная из них это регулярное возникновение непредвиденных событий, отправляющая наш проектный план или же диаграмму бизнес-процесса в мусорную корзину. В проектном менеджменте этому пытаются противостоять при помощи дисциплины управления рисками. BPM предлагает несколько иной подход. И нельзя не признать, что за последние 2-3 года BPM сообщество продвинулось в решении данного вопроса. Одно из названий этого направления Case management.

Обсуждение тонкостей перевода см. в журнале Анатолия Левенчука:
Case management перестало рассматриваться только как работа с кейсами пациентов в клиниках и клиентов юридических бюро. Это теперь такой BPM мейнстрим… далее

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

На сегодня это основная проблема принятия предприятиями BPM. Спросите себя, какую часть своих повседневных активностей вы реализуете при помощи систем управления бизнес-процессами (BPMS), а какую при помощи телефонных звонков, сообщений электронной почты, чтением или написанием текстовых документов и электронных таблиц. А тем временем, значительная часть ресурса ИТ-отделов только тем и занята, что адаптирует существующие информационные системы под непрерывно меняющие потребности пользователей. Подавляющее большинство современных BPMS и Workflow систем разработана в предположении, что все виды деятельности, задачи, шаги, ветвления моделируются априори (т.е. известны заранее с высокой степенью точности). Альтернативный подход заключается в предоставлении ИТ-решений, поддерживающих передачу задач между исполнителями и отслеживание их статуса. Данные системы в большей степени ориентированы на фиксацию успешного опыта, приобретенного при решении аналогичных задач в прошлом в специализированных базах знаний, предоставление набора альтернативных действий, подходящих для данного случая и мониторинга текущего исполнения дел.

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

В 1995 году меня пригласили работать в ОАО АБ «Инкомбанк» в качестве эксперта по системам цифровой подписи. На протяжении нескольких лет я занимался разработкой и сопровождением систем межбанковского документооборота и систем «клиент-банк».

С 2000 по 2014 год работал в ОАО «Вымпелком» (торговая марка «Билайн») на разных позициях: ‘эксперт по информационной безопасности, менеджер проектов по развитию value-added services, руководитель отдела проектирования ИТ-систем. В настоящее время руководитель департамента архитектуры систем поддержки бизнеса. Текущие профессиональные обязанности включают организацию разработки ИТ-архитектуры для проектов компании, управление текущей и построение целевой архитектуры, интеграцию приложений.

В 2015-2016 г.г. Главный архитектор информационных систем Банка России

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