Что роднит BPM и кейс менеджмент

Брюс Сильвер пишет о том, что case managment нацелен на решение тех же управленческих проблем что и BPM:

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

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

Case Management for Knowledge Work

Вебинар Workflow management coalition, состоявшийся 3 марта необходимо посмотреть всем, кто интересуется данной темой. Доступны как слайды, так запись вебинара case management for knowledge work

Несколько идей тезисно:

Knowledge worker – это тот, кто лучше всех в организации разбирается в определенной задаче. (моя вольная интерпретация Друкера)

BPM базируется на следующих допущениях: ваш процесс предсказуем и четко определен; его можно автоматизировать; увеличение “объемов производства” позволяет вернуть вложенные средства. О последнем необходимом условии забывают чаще всего. Интересно, сумел ли Адам Смит продать все булавки, произведенные после эксперимента с разделением труда?

Work-around – старейший киллер производительности труда

Accenture 2009: Companies need to treat innovation with the same discipline as other functions. The most successful companies are generating profitable revenue by managing innovation as a business process.

Enterprise Developer Conference

Пока в Интернет появился всего один отчет о прошедшей накануне Enterprise Developer Conference, а именно размышления Андрея Колесова. Выскажу свои соображения о прошедшем мероприятии. Вернее, не столько о мероприятии сколько, о затронутой теме: разработка ПО внутренними силами предприятия. О самой конференции еще наверняка напишут.

Итак, кто же все эти люди, разрабатывающие ПО, но не являющиеся сотрудниками ни Microsoft ни IBM, ни даже компаний системных интеграторов? Зачем Microsoft собрал их на эту встречу и чему хотел научить? В общем-то, большинство докладов было посвящено именно разработке. Организаторы честно запускали Visual Studio, создавали контролы и редактировали фрагменты кода. Вот только радости участникам конференции, на мой взгляд, это практически не доставляло. Среди гостей мне удалось распознать несколько знакомых ИТ-менеджеров, преподавателей ВУЗов, учебных центров и нескольких журналистов. Вряд ли они так уж часто открывают интегрированные среды разработки. Наверное, потому и не было особой радости на их лицах. Конечно, были и настоящие разработчики, но большинства они не составили. Вспомните «Волшебный котел» Эрика С. Реймонда утверждающего, что до 95% программного кода пишется вовсе не на продажу, а для собственных нужд. Может быть это время ушло(«Волшебный котел» написан в 1999г.) и компании полностью передали разработку ПО на аутсорс? Что-то я сомневаюсь. Скорее внутренние разработчики банков, страховых компаний и прочих предприятий просто не ожидали, что для них может быть организована специальная конференция и потому не пришли. В лучшем случае ограничились просмотром трансляции конференции в Интернет. Потому и тема собственной разработки так и осталась не раскрытой.

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

Впрочем, начало разговора положено. Будем ждать продолжения.

Direct Graph Markup Language

Был вчера на конференции Enterprise developer conference. О конференции чуть позже, сначала про DGML.

Microsoft встроил в Visual Studio функционал построения графических моделей из проектных репозиториев, разработав попутно для этого XML-based язык описания ориентированных графов. Какие объекты использовать в качество узлов графа(сборки, неймспейсы или классы) решать архитектору. Думаю, без больших проблем можно использовать и другие объекты. Или же просто нарисовать такую картинку как эта

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

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 систем разработана в предположении, что все виды деятельности, задачи, шаги, ветвления моделируются априори (т.е. известны заранее с высокой степенью точности). Альтернативный подход заключается в предоставлении ИТ-решений, поддерживающих передачу задач между исполнителями и отслеживание их статуса. Данные системы в большей степени ориентированы на фиксацию успешного опыта, приобретенного при решении аналогичных задач в прошлом в специализированных базах знаний, предоставление набора альтернативных действий, подходящих для данного случая и мониторинга текущего исполнения дел.