Именно так бы охарактеризовал я своё впечатление от прошедшей сегодня конференции CNews BPM 2011: направления развития. К сожалению, я не смог выслушать два последних выступления но и остальных докладов хватило для того чтоб понять, что призрак adaptive case management потихоньку пробирается из Европы и в нашу страну. Причем, если старожилы BPM сообщества в своих докладах упоминали термин case management, то «новички» рассказывали про BPM в стиле «управление и автоматизация бизнес-процессов без консервантов BPMN». Но обо всем по порядку:
Читать далее…
В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Читать далее…
Пришло время испортить бочку светлого меда адаптивного кейс-менеджмента небольшой ложкой дегтя. Довольно много сказано о потенциальных опасностях, подстерегающих BPM проект. Можно посмотреть здесь или здесь. Мне наиболее близка точка зрения Андрея Коптелова, изложенная в Russian ARIS Blog:
Основная сложность внедрения процессного подхода в российских компаниях заключается в необходимости изменения существующих бизнес-процессов, а значит и привычного распределения полномочий и ответственности.
Сопротивления изменениям не просто характеристика отдельных людей, а скорее свойство человеческой натуры. Как, впрочем, и недостаток дисциплины и терпимости. Не буду дальше распространяться на эту тему. Лучше чем у Алистера Коберна у меня это все равно не получится. Желающих углубиться в тему отсылаю к Главе 2 «Индивидуумы» его книжки «Быстрая разработка программного обеспечения». Мы же примем эти особенности людей как данность и поразмышляем о том, как этот прискорбный факт повлиял на эволюцию BPMS. Читать далее…
Управляющие процессы изобилуют корректирующими петлями (запросами на проверку и уточнение)
Не маленьких размеров камешек забросил в огород любителей тяжеловесных формализованных процессов Алистэр Коуберн в работе «The New Face of Software Engineering». Алистэр очень педантичный исследователь и потому, разбирая ту или иную тему, докапывается до сути. Его рассуждения интересны и поучительны.
В упомянутой работе Коуберн использует для процессов разработки программного обеспечения модели, присущие промышленному производству. Как известно, процесс промышленного производства описывается последовательностью работ по преобразованию сырья и материалов в готовые изделия. Процесс проходит несколько стадий. На каждой из которых, результат предыдущих стадий преобразуется в комплектующие для следующей. Пусть так. По аналогии с предложенным подходом мы можем представить интеллектуальную деятельность как упорядоченную последовательность принятия различных решений. Изображенные на картинке пирамидки и есть такие решения, кусочки информации, передаваемые от одного участника процесса другому. Однако, в интеллектуальной деятельности сплошь и рядом случаются ситуации, когда исполнитель очередного этапа просто не может выполнить свою работу из полученных комплектующих. Одни решения не понятны, другие не полны, третьи противоречивы. Во всех этих случаях требуется возврат к одному из предыдущих шагов и повторное прохождение по всей цепочке. Согласитесь, в повседневной офисной деятельности многократная доработка и пересогласование документов это правило, а не исключение. Это как путешествие по лабиринту, когда обнаружив тупик на одном из путей, мы возвращаемся к развилке и идем в другую сторону.
Не понятно, почему же менеджеры высокотехнологичных проектов, прекрасно понимая, что найти решения с первого раза получится далеко не всегда, по прежнему верят в диаграммы Ганта и метод критического пути.
