Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
DbD vs DbD или новое слово в BPM

Не так давно Джим Синур опубликовал в своем блоге  серию статей на тему «От «работы по заданному проекту» к «проектированию в процессе работы»». Эти публикации вызвали множественные обсуждения среди специалистов BPM.  Интересна эта тема в первую очередь потому, что Синур, по сути, предсказывает, куда будет развиваться BPM в будущем.

Джим Синур «BPM в разгаре»:

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

Работа по заданному проекту (Doing by Design)

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

Проектирование в процессе работы (Design by Doing)

Не каждый труд настолько интеллектуален, и некоторые работы подразумевают большую долю совместного труда.  Здесь case-менеджмент добился определенных успехов, но мне кажется, что одного этого не достаточно. Мы должны уметь использовать технологии выявления процессов, чтобы найти лучшие паттерны, и предложить альтернативы для работников умственного труда на примерах успешного применения этих паттернов, и предоставляя им выбор из нескольких вариантов.

Предпочтительная смесь

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

Дальше Синур развивает эту мысль в отдельных заметках.

Моделирование процессов: работа по заданному проекту

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

«Ручное» моделирование

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

Легковесные инструменты моделирования

Аналитик Gartner Билл Россер называет это «моделирование процессов для масс»: для совместной работы используются простые инструменты моделирования. Они легкодоступны, например, как Visio, инструменты моделирования «в облаках», и/или другие простые в использовании инструменты. Это могут быть инструменты, сфокусированные на стратегию, архитектуру, генераторы моделей, управляемых правилами (редко) и/или упрощенные инструменты моделирования. Этим средствам порой не хватает контекста, но они дают возможность начать.

Тяжеловесные инструменты моделирования

Эти инструменты содержат множество функций и требуют экспертов чтобы решить, как ими воспользоваться. Преимуществом такого рода технологий является то, что они дают возможность ссылаться на контекст. К ним относятся инструменты моделирования архитектуры предприятий (EA), глубокие инструменты моделирования процессов и данных и инструменты моделирования исполняемых моделей. Если организации хотят получить очень подробное и/или ссылающееся на общий контекст описание, то использование этих технологий имеет смысл, но они требуют трудоемкой поддержки.

Сделать, попробовать, исправить при помощи средств  исполнения процессов

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


Можно использовать любой из подходов, так как модели сегодня довольно легко можно перемещать при помощи XPDL в BPMN. Ваш выбор может зависеть от вашей культуры, размеров и толщины кошелька. Работа по заданному проекту (DoingbyDesign) актуальна для наиболее статичных частей сквозных процессов.

Проектирование в процессе работы: расширение поведения BPM

Это получится оживленный блог, потому что, вероятно, он вызовет реакцию. Я сравниваю BPM-путешествие с состояниями воды. Сегодня процессы, подобны льду, медленно тающему и делающему молекулы более гибкими. BPM станет комбинацией твердого, жидкого и газообразного состояний одновременно. Моделирование процессов (работа по заданному процессу) в целом представляет собой твердый BPM, который смягчается с течением времени для адаптации к меняющимся условиям.

Как только BPM приобретет больше аспектов «проектирования в процессе работы», он привлечет новую аудиторию, таких как работники умственного труда, на разных уровнях организации. Gartner вызывает такой BPM «Социальный BPM», когда выявление и обеспечение взаимодействия становится все более важным и распространенным.

В процессах, которые являются чисто совместными и динамичными, процесс идет там, где он хочет, руководимый работниками умственного труда, до тех пор, пока он остается в рамках ограничений (особый вид политики и правил) и останавливается в точках определенных KPI. После этого путь процесса, взаимодействия и столкновения с ограничениями можно отслеживать автоматически, чтобы выявить повторяющиеся паттерны успеха, лучшие и худшие практики. Это, в свою очередь, даст работникам умственного труда знания, информацию о паттернах, которые успешно поддерживают творческое взаимодействие с отдельными лицами внутри организации, в рамках цепочки создания ценности, специалистов за пределами организации, а иногда и всего коллектива. Такому выявлению процессов, которое  я называю «проектирование в процессе работы», способствовала автоматизированные технологии и социальный BPM, который предлагает альтернативы и дополнительные знания для работников умственного труда верхнего уровня.

Кое-кто называет это «case management», но я думаю, что люди пытаются подогнать старые технологические паттерны для чего-то нового . Лучше назвать это «адаптивным case менеджментом» , но это все равно не полностью описывает то, куда движется BPM.

Кейт Свенсон не соглашается с утверждением Джима о том, что настоящий BPM должен включать оба этих подхода, называя при этом следующие причины:

Традиционный BPM явно склоняется к подходу «работа по заданному проекту». В огромном количестве источников вы можете прочесть, что работа начинается с описания процесса. OMG работает над BPMN именно в этом подходе.

Однако, что вы думаете о компаниях, подобных Fujitsu или HandySoft, которые уже много лет предлагают подход «проектирование в процессе работы». Мой опыт и мои огорчения заключаются в том, что люди совершенно путаются, когда вы пытаетесь объяснить им, что проектирование в процессе работы – это и есть BPM. Они скажут вам, что бизнесмен никогда не станет использовать BPMN моделлер в своей работе. И они правы! Кто сказал, что для BPM обязательно нужен BPMN моделлер? Все! Эта уверенность преобладает. Но вы можете представить себе доктора, который сидит у себя в кабинете и рисует BPMN-диаграмму для планирования лечения пациента? Не в этой жизни!

Я искренне надеюсь, что Джим и Gartner смогут убедить мир в том, что BPM можно сделать без моделирования, без WSDL, без проверки исполнения, без сложных манипуляций с данными, и без всех тех вещей, которые бизнесмен делает при проектировании. Не многие аналитики являются столь же открытыми, как Джим Синур, и большинство ученых мужей считают весь этот набор необходимой частью BPM.

Посмотрите на любую рекламу: «BPM тренинг» почти всегда включает в себя BPMN тренинг. Я хочу спросить, видел ли кто-нибудь BPM тренинг, который ориентирован на бизнесмена, врача, юриста или судью?

Не важно, какой термин мы используем, до тех пор, пока мы согласны с определением. Если мы хотим назвать оба подхода BPM, то ради бога, если только общественность понимает их смысл. Мой опыт показывает, что люди не понимают, что «проектирование в процессе работы» - это абсолютно другой подход, чем «работа по заданному проекту». Я считаю, что общественность будет сбита с толку, если приклеивать одну и ту же этикетку на оба подхода. Смешивать эти термины с таким количеством значений – это может стать медвежьей услугой.

Вместо этого необходим четкий термин для «проектирования в процессе работы», и этот термин – Case management и его новая техническая реализация – Адаптивный case management. Давая четкое определение для «проектирования в процессе работы», мы поможем людям понимать, о чем идет речь, что требуется и чего не требуется, и это поможет этой новой рыночной форме.

Скотт Фрэнсис, Doing by Design vs. Design by Doing:

Я не знаю, почему бы не назвать его просто «проектирование в процессе работы», и использовать его в качестве этикетки для вашего продукта... ACM не совсем то же самое, и не настолько близко, чтобы связывать это. Попытки преобразовать полезные фразы в трехбуквенные аббревиатуры – это, конечно, в компетенции технарей и софтверных компаний.

На самом деле, я думаю, самое простое объяснение для внезапного желания штамповать новые фразы у фирм, которые раньше были счастливы носить ярлык «BPM», заключается в следующем: группа компаний уже приобрели по одному или по паре BPM вендоров. Сколько еще BPM компаний купят Oracle, IBM, SAP, Software AG и SAP? Вы предпочтете дать более четкое название «XYZ»для купленной компании, как дополнение к BPM компаниям, которые купили раньше, или так и назовете BPM? Конечно! А если вы – большая, известная компания, то сейчас самое время найти возможность выделиться от IBM и Oracle и др.

Я даже думаю, что эта попытка дифференцировать трехбуквенную аббревиатуру логична с точки зрения этих фирм, а также в собственных интересах этих компаний. Но, как и некоторые другие, я хотел бы держать BPM отдельно от BPMS (методологию от технологии).Есть и другие люди, которые устали от погони за новейшими трехбуквенными написаниями, и эти упражнения не идут на пользу клиентам и практикам. Я вижу управление непредсказуемыми процессами как «process-driven», даже если другие так не считают. «Проектирование в процессе работы» звучит для меня как процесс, ребята. Может быть, мета-процесс, но тем не менее – процесс.

Я хотел бы услышать объяснения приверженцев ACM, каким образом они делают «проектирование в процессе работы» проще со своим программным обеспечением – объясните, почему ваше программное обеспечение – это только гаечный ключ, а не отвертка? Объясните рынку, почему программа подходит под определение проблемы? Как врач, я хочу понять, повышает ли ваше программное обеспечение шансы моих клиентов достичь хороших результатов.

В общем, очередные дебаты между сторонниками и противниками расклеивания ярлыков.

=WJ

Комментарии
#1 Максим Смирнов, 18.05.2010 12:04

Очень интересная дискуссия. Похоже, аналитики Gartner присоединяются к аналитикам Forrester в признании роли "нового" case management-а.

Спасибо, за перевод

#2 Юлия Вагнер, 19.05.2010 11:13

Без сомнения, возможность добавления активностей или статусов перехода, активизация любого шага процесса - все эти "ситуационные" действия - вещь полезная. Но когда и зачем? Тут важно не переиграть.
К примеру, если во время исполнения описанного (обычного) процесса возникает ситуация, не предусмотренная моделью процесса - да, необходимо добавить (передвинуть, запустить) что-то волевым решением. Я бы даже после этого не стала бросаться перепроектировать процесс. Скорее, я бы собрала статистику подобных отклонений процесса от заданной траектории, а дальше - либо в консерватории поправлять, либо инструмент подстраивать.
А вот реакция подобного рода: "о, как здорово! Никаких процессов описывать не буду, прямо буду создавать не лету и раздавать задания!" - это меня настораживает. Какой анализ можно сделать на основании такого хаоса? Никаких данных не собрать, неоптимальностей не выявить, улучшать вообще нечего ибо ничего просто нет... тот же бардак, только автоматизированный. Это уже к BPM-у никакого отношения не имеет - об управлении процессами тут речи просто нет.

#3 Максим Смирнов, 23.05.2010 09:04

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

Я думаю, что интерес к теме BPM поддерживается людьми, которые на протяжении многих лет рисовали бизнес-процессы. Они основные заказчики и основной двигатель этого направления. Но позиции их сильны не во всех компаниях. И даже в организациях позволивших себе иметь промежуточный слой между ИТ и руководителями линейных подразделений в виде бизнес-анализа, не обязательно используются BPMN диаграммы.

Однажды, Алистер Коберн назвал UML – большой графической мистификацией. Может быть, и к BPMN имеет смысл относиться с некоторой долей скептицизма. Хотя бы просто для того, чтоб увидеть ситуацию с управлением(!) процессами во всей её полноте.

#4 Валерий Лопатин, 08.07.2010 11:52

Если исходить из концепции, что мы имеем дело с двумя представлениями процессов - шаблонами (описаниями бизнес-процессов на некотором формализованном языке) и экземплярами (реальными процессами, разворачиваемыми в соответствии с шаблонами), то, на мой взгляд, различие между Design by Doing и Doing by Design заключается в следующем: меняем ли мы шаблон в процессе развертывания экземпляра или нет.

Есть два крайних варианта:
- стандартизованные процессы (по одному неизменному шаблону разворачивается огромное количество экземпляров);
- творческие процессы, в которых ничего заранее неизвестно (под одному постоянно меняющемуся шаблону разворачивается один процесс).

Процессы, с которыми мы обычно имеем дело, лежат между этими двумя крайними точками.

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

Конечно можно считать, что все эти варианты шаблона лечения - всего лишь те или иные пути реализации некоторого глобального шаблона, который формально нами не описан. Но так как такое описание нам не под силу (а часто и нецелесообразно), то лучше рассуждать на языке шаблона, который изменяется по мере развертывания экземпляра процесса.

Какой язык для описания шаблона будет выбран (инструкция, диаграмма или иное), на мой взгляд, вопрос второстепенный. Главное - как будет организовано управление версиями шаблона.
И здесь есть над чем работать (известно, что врачи часто забывают, что они собирались с тобой делать в прошлый раз).

#5 Юлия Вагнер, 09.07.2010 13:44

Валерий, все гораздо хужеsmile
Помимо творческих (как Вы их называете) процессов, которые все-таки формализованы, хотя и обладают крайне высокой степенью изменчивости, есть еще и такие, в которых шаблон, если и есть, не является догмой - экземпляр процесса может двигаться по совершенно не предусмотренному шаблоном маршруту. Это и есть Doing by Design, а по-сути - Case Management. И вот вопрос - является ли это BPM - и есть камень преткновения.

#6 Валерий Лопатин, 09.07.2010 18:49

Юлия, чувствую себя не понятым. Чем отличается "постоянно меняющийся шаблон" от "шаблона, который если и есть, не является догмой"? Или вы считаете, что если экземпляр процесса пошел по "совершенно не предусмотренному шаблоном маршруту", то шаблон не изменился? Возможно, под шаблоном вы понимаете только то, что было нарисовано в design-модуле BPMS?

#7 Юлия Вагнер, 12.07.2010 13:09

Да, Валерий, видимо мы по-разному понимаем слово "шаблон". Для меня шаблон - это чисто технологическое понятие, в данном случае - модель в ее графическом представлении в какой-то системе. И я вижу следующие варианты поведения процессов:
1. шаблон описывает все возможные варианты поведения процесса; процесс исполняется исключительно в рамках шаблона. Изменение шаблона предсказуемо и делается всегда заранее.
2. шаблон описывает максимально все траектории процесса. При возникновении непредвиденных случаев процесс идет по непредусмотренной траектории. После анализа отклонения вносятся изменения в шаблон процесса, если случай может повториться или не вносятся, если случай просто "из ряда вон", типа извержений вулкана. Одним словом, всегда стараемся действовать в рамках шаблона, поддерживая шаблон в актуальном состоянии.
3. шаблон, если и существует, догмой не является. Процесс исполняется так, как жизнь подсказывает. Каждый экземпляр процесса имеет свою собственную траекторию. Вот это, на мой взгляд, уже выходит за рамки BPM, поскольку нарушаются сразу несколько принципов: а) повторяемости, б) возможности анализа потенциала улучшений, в) возможность самих улучшений.
Я так понимаю, что с учетом моей поправки на понимание термина "шаблон" у нас пропало ощущение недопонимания? smile

#8 Валерий Лопатин, 14.07.2010 00:33

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

При этом не имеет значения, внес ли владелец процесса формальные изменения в формально существующий шаблон: если по какой-то причине изменения вносятся часто, они скорее всего будут доноситься до субъектов процесса в устной форме, с помощью электронной почты или т.п.

Я понимаю, что BPMS не будет разбираться с тем, что в голове у владельца процесса: не внес изменения в диаграмму - не будет тебе изменений в экземпляре. Хотя, наверное, можно придумать какие-то способы автоматического изменения диаграмм в зависимости от действий субъектов процесса. Например, через механизм бизнес-правил.

Для того чтобы добавить комментарий, вам нужно войти в систему или зарегистрироваться

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати