Маргинальный подход к моделированию бизнес-процессов

В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Читать далее Маргинальный подход к моделированию бизнес-процессов

Впечатления с DOCFLOW 2010

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

Вот ведь люди! Ну, ничего не могут решить без документа. Причем документа, заметьте, бумажного.  А потому, я записываю организаторов конференции в поколение бэби-бумеров. Сама конференций полностью подтвердила мои наблюдения Читать далее Впечатления с DOCFLOW 2010

Worklist applications

Пришло время испортить бочку светлого меда адаптивного кейс-менеджмента небольшой ложкой дегтя. Довольно много сказано о потенциальных опасностях, подстерегающих BPM проект. Можно посмотреть здесь или здесь. Мне наиболее близка точка зрения Андрея Коптелова, изложенная в Russian ARIS Blog:

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

Сопротивления изменениям не просто характеристика отдельных людей, а скорее свойство человеческой натуры. Как, впрочем, и недостаток дисциплины и терпимости. Не буду дальше распространяться на эту тему. Лучше чем у Алистера Коберна у меня это все равно не получится. Желающих углубиться в тему отсылаю к Главе 2 «Индивидуумы» его книжки «Быстрая разработка программного обеспечения». Мы же примем эти особенности людей как данность и поразмышляем о том, как этот прискорбный факт повлиял на эволюцию BPMS. Читать далее Worklist applications

О странностях отношений между SOA и BPM

Бойтесь своих желаний

Если с высоты птичьего полета посмотреть на развитие hype-ов SOA и BPM, и сделать это с некоторой долей юмора, то ситуация будет выглядеть так.

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

Затем на сцену вышла идея управления бизнес-процессами (BPM). Одним из составляющих этого движения явилось появление систем управления бизнес-процессами (BPMS). Непременным атрибутом таких систем является движок для оркестровки сервисов, т.е. разработки некоторых «больших» бизнес-процессов из «маленьких» подпроцессов-сервисов.

А потом появился Adaptive Case Management (он же dynamic case management по версии Forrester и он же advanced case management по версии IBM). Одну из основных идей этого течения я бы озвучил так: «BPMS нам не нужен! Дайте нам сервисы, и мы сами будем складывать из них бизнес-процесс, адаптируя его под каждый конкретный случай по своему разумению». Т.е. бизнес проснулся (сам или же разбуженный вендорами – не так важно) и наконец, осознал все преимущества сервис-ориентированного подхода. И не просто осознал, но уже желает самостоятельно, на лету собирать из кубиков лего-сервисов необходимые ему процессы.

А разве не об этом мечтали несколько лет назад первопроходцы SOA?! 😉

Enterprise architecture vs. BPM

В блоге Анатолия Белайчука появилась заметка Граница между инструментарием EA и BPMS. Желание провести такую границу абсолютно уместно. Не выполненных обещаний архитектуры предприятия, BPM сообщество  просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях, тоже не стоит сбрасывать со счетов. Тем более, что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы: Читать далее Enterprise architecture vs. BPM

Ключевые моменты 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 и модели процессов