| Все о системах управления |  |
| Почитать |
| Поговорить |
| Побродить |
| Завершить |
|
|
||||
|
Обзоры, выпуск 10, 2009 г.
|
|||||
Литература:
2009 - год, когда BPM не оправдал ожиданий?
"2009 – the year BPM really failed to deliver?". Thomas Olbrich, Managing Director, Taraneon Consulting Group.
Сокращения персонала и расходов, перестройка под новую реальность, выживание, новые модели бизнеса... 2009 дал владельцам процессов так много поводов не только для вопросов, но и для решений. Но они в целом не справились:
Не справились, поскольку мы по-прежнему тратим слишком много времени на выявление процессов.
Не справились, поскольку мы по-прежнему настаиваем на том, что автоматизация - это разновидность управления.
Не справились, поскольку мы по-прежнему не поняли что процесс либо создает ценность, либо ее уничтожает.
Не справились, поскольку мы по-прежнему считаем, что любое улучшение внутреннего процесса автоматически приведет к улучшению клиентского процесса.
Не справились, поскольку мы по-прежнему не осознали разницу между управлением процессами и управлением на основе процессов.
Не справились, поскольку мы не привязали процессы к бизнес-стратегии.
Не справились, поскольку мы используем термин "процесс" как фиговый листок, прикрывающий функциональное управление.
Не справились, поскольку нам нет дела до того, как изменяющиеся обстоятельства влияют на процессы.
Не справились, поскольку мы отказываемся заставить владельцев процесса отвечать за тот бардак, который они администрируют.
Не справились, поскольку через 20 лет после первой большой волны реинжиниринга и через 10 лет после того, как стало модно говорить о BPM, нам до сих пор не удалось выработать процессный стиль мышления.
И мы все еще недоумеваем, почему высшее руководство отказывается признавать ценность процессов помимо чисто теоретической? Может кто-нибудь объяснить, как все эти так заманчиво звучащие предсказания относительно процессов в 2010 - облака, SaaS, "зеленые" процессы, BPM 3.0 и т.п. - могут хоть как-то улучшить положение, если они не нацелены в первую очередь на фундаментальные проблемы, с которыми мы сталкиваемся? Заглядывать в будущее - это одно, но если мы не учим уроков прошлого (http://bit.ly/7fMaAY), то будущее просто пройдет мимо нас.
=АБ
>> Комментарии (всего 1)Отзыв о "круглом столе" Cnews 3 ноября 2009 г.
Как и у любого мероприятия, у этого были и минусы, и плюсы, но нужно честно отметить, что плюсы значительно перевешивают. Поэтому с них и начнем.
Мнение, которое четко прослеживалось в кулуарных обсуждениях – это высокий КПД (звучала оценка в 80%) от докладов. То есть содержание и качество докладов было высоко оценено слушателями (согласитесь, что этим «страдают» далеко не все мероприятия подобного рода). Эффекта добавило удачное расположение докладов.
После вступительного слова организаторов «стола», первый доклад Анатолия Белайчука («Бизнес-Консоль»), который назывался «Невыполненные обещания ERP», очень удачно задал общую основу всех обсуждений. И, так или иначе, все докладчики в своих выступлениях ссылались на обозначенную в этом докладе проблематику.
Как сейчас преподносят идеи BPM? BPM – это средство трансформации бизнеса. Но минуточку! А не под тем ли соусом продавались всем известные ERP-системы? Означает ли это, что BPM – это то, что должно заменить ERP? И почему доклад называется «невыполненные обещания»?
В названии EPR, так же как и в MRP, MRP II присутствует буква «P», которая во всех случаях обозначает планирование (planning). Но на деле большинство успешных внедрений ERP имеют результатом налаженный управленческий учет. Это само по себе немало, но планирование, как правило, ведется в Excel, полуручным способом. Специфика планирования такова, что прямая задача – годовой план – план на месяц и т.д. – решается достаточно просто. Проблема возникает при решении обратной задачи – планировании исходя из имеющихся ограничений по сырью, мощностям и т.д. Решение у этой задачи только одно – многократные итерации решения прямой задачи. При этом процесс планирования возвращается на разные уровни, на которых происходят не только расчеты, но и согласования, утверждения. И в решении данной задачи BPM может добавить необходимую динамику и улучшить качество планирования. В отличие от учета, который не влияет на бизнес-результат, качество планирования влияет на увеличение продаж и сокращение издержек. Кроме того, BPM позволяет вовлечь в процессы людей, чье общение с системой настолько эпизодическое, что нет смысла обучать их тяжелому интерфейсу ERP.
Из доклада Анатолия видно, что для достижения ощутимых преимуществ от использования BPM, необходима твердая опора в виде ERP. BPM определяет порядок выполнения операций и взаимодействий, ERP предоставляет информационные объекты, над которыми выполняются операции. В связке они дают динамику, превращая пассивную систему в активную. «ERP без BPM лишен бизнес-целей. BPM без ERP лишен точки приложения усилий».
Дальше Анатолий сказал несколько слов о преимуществах и недостатках встроенных и независимых BPM-систем. К преимуществам встроенных систем он отнес возможность доступа к функциям ERP без дополнительной интеграции. Однако заметил, что вовлечение большего числа пользователей может повлечь необходимость покупки большего количества лицензий. Независимые BPM, по мнению докладчика, имеют больше преимуществ, среди которых он выделил следующие:
- для моделирования и участия в исполнении бизнес-процессов не обязательно быть опытным пользователем ERP
- расширенная функциональность: round-trip, быстрое прототипирование, имитационное моделирование (simulaton), бизнес-правила (BRE), аналитика (BAM)
- развитые средства интеграции
К тому же, вся эта функциональность в независимых системах доступна уже сегодня, в то время как ERP-вендоры о ней только заявляют.
Дальше следовал доклад Романа Ткачева («BI Telecom»), который рассказал об опыте реализации двух пилотных проектов в ВТБ-24.
Цели данных проектов были обусловлены самой спецификой банковского бизнеса. Для банков непременным условием успеха является скорость реакции на изменения рынка. Здесь важен быстрый запуск новых продуктов и изменение условий для уже существующих. К тому же, обычные требования, присущие любой компании - сокращение операционных и непроизводственных затрат и повышение производительности сотрудников.
Компания BI Telecom предложила решение на базе BPM-система Lombardi TeamWorks.
Первый пилотный проект «Обработка кредитной заявки» ставил цели обеспечить сквозной оперативный контроль процесса, создать единый интерфейс для сотрудников, добавить функциональность, не реализованную в АБС и создать унифицированный процесс для всех регионов с разными АБС. После запуска процесса в системе работают несколько десятков пользователей, ежедневное количество запускаемых экземпляров процесса – несколько десятков, активных экземпляров – несколько сотен. Результат проекта - отработан процесс/технология «заявка-обработка-выдача» для кредитного продукта; каждый экземпляр процесса можно контролировать в он-лайн. Роман указал в докладе, что целевое количество пользователей и процессов в десятки раз больше. Но надо отметить, что даже существующие показатели – это хороший результат, которым могут похвастать не все подобные проекты.
Результат второго проекта – «Управление продажами» - отработан новый процесс привлечения клиентов, осуществления кросс-продаж, формирование отчетности.
Помимо отдельных успехов по каждому проекту, есть и общие достижения, значимость которых сложно переоценить. Во-первых, отработана технология реализации BPM-проектов. Во-вторых, четко определено место BPM-платформы в ИТ-архитектуре банков. В-третьих, создан центр компетенции BPM.
Доклад Евгения Самбу (DocsVision) выделялся на фоне остальных докладах отсутствием новизны. Первая часть доклада – банальный ликбез на тему «что должны уметь BPM-системы». Дальше – про отличие BPM-систем от Workflow. И, естественно, рассказ о возможностях DocsVision. С подобным докладом можно было выступать два-три года назад, когда народ еще только присматривался к «новому зверю – BPM». А уровню данной аудитории доклад явно не соответствовал.
Название доклада Алексея Борисова (IDS Scheer) – а доклад назывался «Будущее BPM начинается сегодня» - оказалось гораздо скучнее, чем сам доклад. Подходящим названием для доклада был, скорее, заголовок пятого слайда: «Что нового в продуктах ARIS». И это действительно то, что могло заинтересовать аудиторию, поскольку IDS Scheer настолько крупный игрок на рынке, что держать руку на пульсе приходится и заказчикам, и другим вендорам. ARIS действительно сделал несколько прорывных вещей в части моделирования диаграмм. Научился работать с BPMN-нотацией. И научился экспортировать диаграммы в исполняемые движки. И, как следствие, появление аналитического ПО и методов, комбинирующих технологии управления бизнес-процессами (то, чего раньше ARIS не умел) и бизнес-аналитики (BI). Назвали они этот продукт Process Intelligence (PI), хотя в скобках по-прежнему пишут PPM (этот продукт известен уже давно). (Главное, чтобы сами не запутались 
)
Еще одно направление, на котором Алексей сделал акцент – это процесс управления процессами. ARIS Process Governance – это длинный список того, чем ARIS умеет управлять: жизненным циклом модели, ИТ-архитектурой, изменениями и т.д.
Как известно, не так давно произошло слияние IDS Scheer с не менее крупным игроком на рынке BPM – компанией Software AG. Таким образом, ARIS дальше будет развиваться в связке с WebMethods. И о некоторых перспективах такого развития Алексей также рассказал в своем докладе.
Очень живым и свежим показался доклад Алексея Будина («Элевайз»). Казалось бы – так же, как и DocsVision, представлял свой продукт – систему ELMA. Но сделал это Алексей не в академическом стиле, а очень живо и интересно. Алексей построил свое выступление как представление двух взглядов – взгляда управленца и взгляда производителя продукта, продавца. Учитывая, что ELMA для большинства присутствующих до сего времени не была известна, то такое ненавязчивое заявление о себе со стороны «новичка» было воспринято легко и доброжелательно.
После небольшой кофе-паузы народу в зале поубавилось – кое-кто счел, что основное он уже услышал и можно уходить. Но тем хуже для них. Не так часто приходится слышать доклады компаний, для которых мыслить процессно – это не общие фразы. А таких докладов было целых два!
Первый из них – доклад Алексея Бойко, представлявшего «КЭС-Холдинг». (КЭС – это комплексные энергетические системы). Доклад назывался «Специфика внедрения BPM в энергетике». Можно было бы дать докладу второе название – «выживание BPM в условиях кризиса».
Начиналось все с решения строить операционно-инвестиционную энергетическую компанию. Разработать стратегию, построить бизнес-модель на основе описания бизнес-процессов и большое количество других задач – структуры, регламенты и проч. В результате, за год было достигнуто следующее: утверждена операционная модель холдинга, сформирована и утверждена модель процессов верхнего уровня, в соответствии с которыми были сформированы дивизионы. Сформированы дивизионные модели процессов второго уровня, их организационные структуры, регламенты междивизионного взаимодействия на основе процессов второго уровня.
И тут наступил переломный момент (кризис)! В этих условиях задачи стали позиционироваться иначе. Все силы брошены на проблемные области, оставляя в покое более-менее стабильные, даже если последние имеют больший потенциал для улучшений. При распределении ресурсов предпочтение отдается проектам, пусть менее системным, но приносящим быстрый результат. Сокращение расходов, не влияющих напрямую на показатели деятельности (и к этим расходам в первую очередь относятся все проекты по бизнес-процессам). И вот тут надо отдать должное процессной команде! Что они сделали? Они тоже переставили акценты.
Бросить все силы на проблемные области? Отлично! Концентрируем усилия на проблемных областях, но при этом держим общую картинку и модель процессов всегда в голове. На время сворачиваем массовые «ковровые» активности в описании бизнес-процессов и концентрируемся на поддержке проектов, приоритетных для Бизнеса.
Предпочтение проектам, приносящим быстрый результат? Пожалуйста! Быстро решаем поставленные задачи, ищем наряду с бизнесом области «быстрых» побед. Но не забываем про системные «долгоиграющие» вещи, пытаемся найти компромисс между «быстро» и «всерьез и надолго».
Сокращение расходов? Ну что поделать? Пытаемся решить две задачи одновременно: сократить (оптимизировать) расходы на ПО и нарастить процессную компетенцию внутри (не всегда есть возможность привлечения внешнего подрядчика по БП)
И дальше меняем подход к реализации проекта перехода к новой операционной модели от «сверху вниз» к «снизу вверх». В плоскости построения систем управления - концентрация усилий на приоритетных системах управления (бюджетирование, казначейство, бизнес-планирование). В организационной плоскости - участие в проектах по организационным преобразованиям, действуя по принципу «оптимальные процессы – оптимальная структура». В процессной плоскости - наращивание внутреннего потенциала процессных аналитиков без существенных затрат на ПО. В ИТ - участие в унификации и оптимизации процессов до и во время внедрения. И участие во всех значимых проектах для бизнеса в качестве руководителей проектов и в качестве бизнес-аналитиков.
Ничего не могу добавить. Мудро.
И второй доклад Александра Башкова («Тетра Пак») – «Опыт создания и управления процессной моделью компании». Если вам нужен передовой опыт крупной международной компании – вам сюда. Содержание доклада полностью соответствовало названию. Мою реакцию можно описать так «Ну, вот есть же! А вы говорили…». Конечно, Тетра Пак – компания международная, и стандарты во многом продиктованы этой «международностью», но было б на пользу!
Андрей Михеев (Консалтинговая группа «Руна») затронул не менее актуальную тему – взаимодействие BPM-систем с системами управления контентом (ECM). Доклад назывался. «Интеграция свободной системы управления бизнес-процессами с ECM-системами и порталами».
Почему нельзя просто использовать BPMS вместо ECM или наоборот? Разобраться порой действительно трудно, поскольку сейчас многие ECM системы имеют workflow-движки, а многие BPM-системы реализуют подобие документооборота. Андрей, как практик, очень четко сформулировал ответ на этот вопрос.
В ECM встраивают workflow-движки, но полноценной системе управления бизнес-процессами ECM, как правило, уступает из-за отсутствия поддержки возможности быстрого изменения бизнес-процессов. То есть в ECM можно реализовать бизнес-процесс, но трудно менять его в оперативном режиме. В ECM же имеется удобная навигация по документам, контекстный поиск, контроль версий документов, система разграничения прав доступа к документам, интеграция с MS Office и Open Office. Дальше Андрей привел пример интеграции системы управления бизнес-процессами Runa WFE и ECM-системы Alfresco.
Еще Андрей продемонстрировал результат интеграции Runa WFE в JBoss Portal. Чего в этом особенного, если все BPM-системы имеют свой портал? Runa WFE - это собственная разработка «Руны» на основе OpenSource JBPM, в которой своего портала нет. Зато есть свои преимущества, такие как отсутствие затрат на приобретение системы, неограниченное количество инсталляций, простота установки, возможность участия предприятий, использующих систему, в ее разработке.
Завершил блок выступлений Владимир Алешин, профессор Академии Народного Хозяйства при Правительстве РФ. Вот уж где сразу виден преподаватель. В какие-то моменты чувствуешь себя студентом 
. Его доклад «Внедрение BPMS – необходимое, но не достаточное условие перехода к SOA» вызвал оживление в зале. Для BPM нет иных перспектив, как, только в связке с SOA. А для организаций нет другого пути, как сервис-ориентированная архитектура. Особо возражать докладчику никто не собирался, но Владимир говорил настолько убежденно и живо, что дискуссия (а скорее – обмен мнениями) просто не могла не возникнуть. Так что «круглый стол» завершился в приподнятом настроении.
Да, многих это немало удивило – на этом «стол» завершился. Обещанной дискуссии не было 
. К сожалению, - и этот тот минус, о котором нельзя не сказать, - круглый стол лишили его основного назначения. Дискуссия переместилась в кулуары, но потеряла свою остроту. К тому же, многие участники просто не пошли повторно в фойе, так что пообщаться можно не со всеми. Минус существенный, но зато организаторам останется возможность совершенствоваться.
Многие вендоры проигнорировали мероприятие – возможно, сказалось урезание бюджетов. И спонсор был в этот раз только один – BI Telecom. Но народу было достаточно (по данным разведки – 105 человек), зал был полон.
И напоследок хочу поблагодарить организаторов за интересное, содержательное мероприятие. Спасибо.
Ссылки по теме:
- Информация о конференции на сайте CNews
- Отзыв о конференции на блоге Анатолия Белайчука
- Аналитическая статья CNews по материалам "Круглого стола"
Презентации участников круглого стола:
ERP и BPM - вместе или вместо?
Практически любая ERP система сейчас уже имеет встроенный BPM движок. Однако, при этом, споры о том, нужен ли BPM, когда уже есть ERP по прежнему не утихают.
Как правило, встроенные в ERP BPM неплохо справляются с большинством жестко регламентированных процессов, по сути являясь workflow маршрутизатором. Но как раз самые непредсказуемые и не поддающиеся жесткому описанию процессы, которые не умещаются в рамки ERP-систем, и являются на деле самыми трудно управляемыми.
Гарт Кнадсон (Garth Knudson), управляющий директор HandySoft, в своей статье «Transforming Email 'Noise' into Business Process Knowledge» определяет два типа BPM – структурированный и динамический.
"Структурированные" BPM идеально подходят для автоматизации формализованных потоков работ (например, закупки, прием, соблюдение нормативов, расходы). Тем не менее, они не предназначены для поддержки постоянно меняющихся потоков работ (например, выдача заданий, отслеживание действий, управление проектами), что занимает 80 процентов среднего рабочего дня. В результате, умственные работники (сегодняшние белые воротнички, инженеры), естественно, обращаются к электронной почте для динамической работы. Электронная почта стала в буквальном смысле нашей повседневной железной связью для начала, слежения и завершения динамической работы или "раздатчиком заданий".
Т.е., по мнению автора, недостающие коммуникации в отсутствии динамического BPM, сотрудники восполняют посредством электронной почты. Но электронная почта не является достаточно надежным инструментом, поскольку информация в ней не структурирована, может являться недостаточной либо избыточной (что добавляет сложности в ее обработку), плохо поддается контролю.
На эту статью появился интересный отклик на одном из блогов «BPM or ERP or Both?». Автор обобщил вопросы, которые возникают в обсуждениях темы:
- Как сравнивать ERP и BPM?
- Конкурирует ли BPM с ERP, должен ли он заменить ERP или они могут сосуществовать вместе?
- Что я могу получить от BPM?
- Что делать в первую очередь?
Отвечая на эти вопросы, автор пишет:
ERP: проще говоря, я вижу ERP как способ интегрировать слой данных различных процессов(например, дебиторская/кредиторская задолженность, штатное расписание, ввод заказа) в более общие процессы (например, финансы, управление персоналом, управление цепочками поставок). Хотя workflow и является встроенной частью ERP, но он не предназначен для поддержки сквозных процессов. Workflow сам по себе идет «от функций» (например, от управления материалами), а не «от процессов», где процессы охватывают много различных функций (например, требования, набор персонала). Ценность ERP в том, что она представляет собой интегрированную систему с обобщенными данными. Данные обновляются по требованию. Заказчики ожидают от ERP поддержки своих процессов, и зачастую им приходится менять свои процессы, подстраиваясь под ERP. В результате стоимость ERP и его внедрения довольно высока.
BPM: в отличие от ERP, BPM позволяет создавать бизнес-приложения, включая разных людей, данные, документы, которые, в свою очередь, охватывают несколько подразделений, систем и/или источников данных. Для процесса функции не имеют почти никакого значения. В структурированном BPM действия определяются конкретными правилами (например, роль, ответственность, политика, процедуры, сроки, эскалация). В динамическом BPM пользователи контролируют маршрут прямо во время исполнения. Ценность BPM в том, что это платформа для создания различных приложений, которые повышают производительность (эффективность, отдачу), гибкость бизнеса (отслеживание, инновации, оптимизация), соответствие законодательству (возможность аудита). Более того, компоненты, определяемые в процессе, являются многократно используемыми и изменяемыми.
BPM может конкурировать и/или замещать ERP в мелких проектах. BPM желательно использовать вместе с ERP для создания «единого взгляда» на процессы, распространяющиеся на несколько групп/систем (например, привлечение заказчиков, заказ на приобретение). BPM также охватывает процессы, которые полностью выпадают из ERP, такие как управление перепиской, управление проектами, отслеживание действий.
Автор приводит два примера совместной работы ERP и BPM.
Первый пример – нефтяная индонезийская компания. Часто компании приходится изменять заказы на основании изменения проектов и сроков. Но после того, как они внесены в ERPсделать это невозможно, поскольку эти процессы охватывали сразу несколько модулей ERP. Компания решила использовать BPM для управления жизненным циклом проектов. Теперь менеджеры проектов могут инициировать и отслеживать контракты, переговоры, закупки нового оборудования, а также изменения в сроках проекта. ERP управляет данными. Совместное управление ERP и BPM дает единый взгляд на данные и процессы.
Второй пример - дистрибутор товаров для здравоохранения по всей Латинской Америке. Они используют ERP как адресную книгу, чтобы управлять поставщиками, покупателями и расчетами. Т.к. изменения в адресную книгу могут вносить представители разных департаментов (HR, ИТ, отдел закупок) в различных странах, то присутствовала полная неразбериха из-за разных подходов к ее ведению. Слабый контроль над процессом, нечеткие данные – все приводило к срывам сроков, пропаже товаров и, как следствие, к недовольству и потере клиентов. Что реализовали в BPM: каждый пользователь начинает работу с одной точки, независимо от того, в каком департаменте он работает. Дальше процесс проходит все службы, где подтверждается оплата и прочие данные, и только после этого данные передаются в ERP.
Резюмируя,
- ERP обладает хорошим встроенным workflow, но слабоват для сквозных процессов. BPM поддерживает как функциональный workflow, так и кроссфункциональный для предприятия в целом
- BPM гораздо более гибкий нежели ERP. Там где для внедрения BPM требуется три месяца, ERP потребуется двадцать. Управление изменениями в BPM также быстрее
- BPM нужен ERP, для того чтобы получить от него максимум отдачи
- Если BPM не используется вместе с ERP, то почему же тогда вендоры предоставляют всевозможные адаптеры к нему?
Итак, BPM, ERP или оба? Автор этим вопросом свой пост завершает, но интересны два комментария к заметке.
В первом комментарии: прежде, чем внедрять ERP, необходимо "плавно" приучить работников к системной работе. И сделать это при помощи BPM. Все равно прежде чем внедрять ERP, консультанты составляют карты процессов… затем все о них забывают, внедрение длится очень долго… Ну а дальше своеобразный вывод: все равно работа по автоматизации процессов в BPM не пропадет даром, поскольку потом эти процессы будут перенесены в ERP. Т.е. автор комментария считает, что BPM стоит использовать на начальном этапе перед внедрением BPM. И даже соглашается, что это дополнительные расходы, которые, в прочем, быстро окупятся. (Напрашивается вывод: внедрим ERP – бросим BPM? А может и не выбросим, поскольку дальше совсем уж оптимистично) Иногда внедрение ERP срывается из-за попытки втиснуть процессы в предопределенные параметры ERP-системы. Чаще всего пользователям приходится подстраиваться под эти шаблоны. Но зато в BPM-системе гораздо проще делать изменения! (Т.е. еще послужит, быть может).
Автор второго комментария рассказал о том, что в беседе с одним из управляющих о преимуществах BPM, тот спросил его «означает ли это, что я могу избавиться от своей ERP системы?». Дело в том, что, он ощущал себя ограниченным рамками ERP. Т.е. ERP давала ему высокую наглядность некоторых оперативных метрик, но ему не хватало гибкости, чтобы реагировать на реальные проблемы. ERP системы наилучшим образом подходят для управления конкретными функциями. BPM же может использовать бизнес-данные, привязав их к повседневным действиям, и организовав взаимосвязь между данными, людьми и системами.
Похоже, что статья Гарта "зацепила" многих, поскольку о ней же пишет и Деннис Байрон (Dennis Byron) и своем блоге, практически резюмируя обе предыдущие заметки. Там же, на блоге Денниса развернутый комментарий ИТ-менеджера одной из компаний, имеющих у себя и BPM и ERP системы. Он отмечает, что все четыре пункта, резюмированные в статье, полностью подтверждаются его практикой.
=WJ
>> Комментарии (всего 0)Плюсы и минусы BPMN 2.0
BPMN 2.0: говорят о ней так часто и так много, что уже не все помнят, чем она отличается от версий 1.х. И еще вопрос, стоят ли изменения, которые ожидается увидеть в 2.0, того, чтобы так долго и с такой надеждой их ожидать?
BPMN – это графическая нотация для изображения бизнес-процессов. Задумана она с целью создания единообразных описаний процессов. Однако в первых версиях нотация не была рассчитана на исполнение процессов в BPM-системе, поэтому разработчиков стандарта мало заботило то, каким образом BPMN-схема будет переведена в XML формат. Все инициативы WfMC в этом направлении не находили поддержки со стороны OMG. Но необходимость создания исполняемых моделей процессов вызвала необходимость создания такой нотации, которая поддерживала бы XML формат и была бы одинаково интерпретирована любой, поддерживающей эту нотацию, системой. Статус стандарта вынуждал бы производителей BPM-систем поддерживать эту нотацию. Таким стандартом претендует стать BPMN 2.0.
Однако далеко не все члены BPM сообщества настроены по этому поводу оптимистично. Условно можно выделить несколько групп различного рода специалистов, ожидания которых не одинаковы, о чем пишет в своей заметке BPMN 2.0 – Marriage Made In Heaven or Trough of Disillusionment Дерек Миерс (Derek Miers), шеф BPM-focus.
«Существуют противоположные лагеря, каждый из которых пытается свернуть спецификацию в своем направлении. Одна группа говорит: «давайте сделаем так, чтобы BPMN отражала потребности BPEL». Другие говорят, что «мы должны сделать BPMN частью UML» (я задаю этот вопрос на каждой конференции… и непременно вижу ужас в глазах). Третьи хотят, чтобы BPMN лучше поддерживал хореографию (лично я хотел бы увидеть нечто, поддерживающее трансляцию в Role Activity Diagrams, который является более мощным подходом к моделированию взаимодействия ролей, чем то, что я видел на сегодняшний день в BPMN 2.0).»
Франк Пулман (Dr. Frank Puhlmann) выделяет две таких группы («BPMN 2.0 drafts»). Первая, в которую входят IBM, Oracle, SAP, Unisys в качестве инициаторов, а также IDS Scheer, Software AG, TIBCO, Intalio и другие предлагает базироваться строго на предыдущих версиях спецификации. В то время как вторая, к которой Франк относит Axway Software, EDS, Lombardi Software, MEGA International, Troux, Unisys в качестве инициаторов (Unisys и тут и там!) предлагают подогнать нотацию под Business Process Definition Metamodel (BPDM). Сам автор придерживается первого мнения, поскольку во втором случае мы получим набор таблиц и фигур, которые сделают модель нечитаемой.
Рассматривая BPMN 2.0 с позиции первой группы, Франк выделяет несколько областей расширения нотации по сравнению с 1.1.
- формализация исполнительной семантики для каждого элемента
- Расширение технических возможностей как для моделирования процессов, так и для графики
- Уточнение событий объединения и корреляции
- Расширение определение человеческого взаимодействия
- Определение хореографию
«Эта спецификация также устраняет имеющиеся в 1.1 противоречия и неясности» (цитата из драфта спецификации)
За границами будущей спецификации остаются такие аспекты как
- Определение организационных моделей и ресурсов
- Моделирование функциональных прерываний
- Модели данных и информации
- Моделирование стратегии
- Модели бизнес-правил (цитата из драфта).
Основным достижением спецификации будет включение XML схемы на основе мета-модели, поддержка хореографии, семантика исполнения, усовершенствованное BPEL-отображение и множество мелких добавлений и исправлений.
Мета-модель, основанная на XML-схеме. Все BPMN элементы описаны в XML, что обеспечивает стандарт мета-модели. Было бы полезно, если бы это было визуализировано.
Хореография. Спецификация вводит третий тип модели – хореографию. Первые два – оркестровка и совместная работа. Хореография – это «определение ожидаемого поведения, по существу, процедурный договор между взаимодействующими участниками. В то время как обычный процесс существует внутри пула, хореография существует между пулами (или участниками)». Проект спецификации определяет ряд правил, по которым могут быть определены задания.
Говоря о хореографии, необходимо упомянуть обмен сообщениями, называемый «conversation», определяемый в BPMN как «набор обменов сообщениями, имеющими одинаковую взаимосвязь». Спецификация определяет несколько видов взаимосвязей (на основе ключей или выражений), тесно связанных с BPEL.
Семантика исполнения. Каждый объект имеет свой жизненный цикл с состояниями, такими как активирован, в работе (исполняется), завершен, выполняется компенсация и т.д. Семантика исполнения – это описание в табличном виде различных состояний объектов процесса. Кроме того, описание непосредственно указывает на соответствующий шаблон процесса. Единственное, чего не хватает – это формального представления. К примеру, описание OR-Join до сих пор еще очень расплывчато. С другой стороны, неформализованное описание оставляет большую свободу исполнителям.
BPEL-отображение. BPEL-отображение является очень существенным шагом. Однако часть ответственности остается на производителях BPM-систем, поскольку такое отображение накладывает на WS-BPEL процесс определенные ограничения. По крайней мере, он должен соответствовать операционной семантике BPMN процесса.
Другие улучшения. Черновик спецификации содержит еще некоторые улучшения, такие как множественные пулы, маркеры для разных типов заданий, сборники данных, расширение взаимодействий между людьми (исполнителями, владельцами). Спецификация определяет расширенную модель, которая может использоваться для интеграции с другими артефактами.
Появился новый вид события, который напоминает символ Star Trek и используется для эскалации. Промежуточные события могут быть представлены в виде подпроцессов.
Один из самых авторитетных аналитиков и специалистов в области BPMN, Брюс Силвер, будучи участником команды разработчиков стандарта, консорциума OMG, в своем блоге часто обращается к этой теме. В заметке «5 Things to Love About BPMN 2.0» он приводит пять основных преимуществ 2.0:
- Обмен моделями между разными инструментами. Представляет собой XML-схему для обмена BPMN моделями, как исполняющими, так и не исполняющими инструментами.
- Не прерывающиеся события. Самым большим отличием BPMN от традиционных диаграмм всегда была поддержка событий. Событие – это сигнал, что «что-то случилось», и BPMN позволяет сказать, что делать с процессом дальше: запустить новый экземпляр, перенаправить по пути исключения, продолжить остановленное действие, прервать запущенное действие. В простых нотациях невозможно изобразить запуск нового действия или потока внутри процесса без прерывания текущего процесса. BPMN это позволяет.
- Пользовательские действия. В BPMN 2.0 есть новый тип событий, называемый эскалация. Эскалация означает сигнал, генерируемый внутри процесса. Пользователь во время исполнения процесса может инициировать действия, обозначенные в диаграмме, отменить событие или же запустить параллельно другое действие.
- Задание - бизнес-правило. Никакой другой аспект PBM не отвечает за такое количество ложной информации, дезинформации и преднамеренное запутывание, как связь между процессом и бизнес-правилами. Это разные вещи, но они должны работать вместе. Основная проблема всегда была в том, что инструменты не позволяют должным образом отобразить бизнес-правила на процессной диаграмме. BPMN 2.0 предлагает новый тип задания, обозначающий вызов бизнес-правила. Это специальный автоматический шаг. В процессной модели он не требует каких-либо действий. Он только возвращает результат правила, который дальше можно использовать в процессной логике.
- Более легкое выполнение событий. Некоторые номинально BPMN-совместимые BPM-системы поддерживают исключения, но не BPMN нотацию для них. Это плохо, поскольку укрепляют уверенность, что работа с исключениями – это уже область ИТ, а не бизнеса. На самом деле это проблема BPM-движков, которые не распознают семантику BPMN. В BPMN 2.0 добавлена специальная конструкция, называемая подпроцессом события. Подпроцесс события запускает подпроцесс в случае возникновения исключений.
Теперь о том, что не вошло в стандарт. Заметки от того же автора (Брюса Силвера) «Five Things They Left Out of BPMN 2.0».
- Различие между информацией, связанной с моделью, и информацией, связанной с исполнением. BPMN 2.0 слишком ориентирован на исполняемые модели и слабо поддерживает информационные элементы, которые могут быть использованы в неисполняемых моделях.
- Семантика неисполняемых моделей. Не удалось избавить модель от таких специфических данных, как WSDL-ссылки и интерфейсы к данным. В семантике BPMN центральную роль играет движок оркестровки не зависимо от того, есть он или нет. BPMN, в сущности, предполагает одинаковую семантику для исполняемых и для неисполняемых моделей. К примеру, сплошная стрелка означает на практике последовательную передачу управления. Т.е. действие А закончилось и немедленно начинается действие В. А как показать, что действие В происходит не сразу или В стартует после запуска А, но не сразу после его завершения? Как показать, что между А и В существует что-то еще? Сейчас такие действия можно изобразить при помощи каких-то дополнительных флагов, т.е. нестандартным образом.
- Переносимость модели. Модель, созданная в инструменте Х, должна открываться в инструменте Y. А это означает, что любой инструмент должен поддерживать BPMN. Но сейчас BPMN используется как нотация для диаграмм, а не как язык исполнения. И с появлением BPMN 2.0 это вряд ли изменится. По мнению Силвера члены команды разработчиков стандарта сами не уверены, насколько их собственный инструмент будет совместим с 2.0 релизом.
- Графический обмен. Силвер поясняет, что когда он говорит о графическом обмене, он имеет в виду такие инструменты как Appian, Lombardi, Savvion, TIBCO, and ITP Commerce. Вместо этого разработчики стандарта стремятся сделать его интегрируемым с такими инструментами, как Eclipse GMF или какую-то смесь UML и BPMN фигур и другими концептуальными вещами, которые далеки от кому в действительности нужен моделлер. Специфическая BPMN информация, такая как размеры, позиции, пулы и дорожки, действия, ветвления или события даже не определены XML схемой, только тем, что называется М1 библиотекой. Т.е. это может быть дружественно UML, но не дружественно XML. В этом случае основные потребители BPMN-спецификации ее попросту не примут.
- Свойства имитационного моделирования. Большинство инструментов имитационного моделирования основываются на параметрах, полученных от действий, исполнителей, ветвлений, событий. Стандартизация таких параметров была пропущена в BPMN 1.х, и имело смысл добавить их в 2.0. Есть разделы спецификации на тему «аудит» и «мониторинг», но ни слова об имитационном моделировании. Имитационное моделирование имеет большой потенциал, и это еще одна упущенная возможность.
Примерно о том же пишет Роберт Шапиро (Robert Shapiro) в заметке BPMN Process Interchange. Он считает, что некоторые нововведения усложнят модели, т.к. нет четкого разграничения атрибутов для исполняемых моделей и для более высокого уровня моделей, которые использует бизнес-аналитик. Кроме того, т.к. портативность модели подразумевает ее интерпретацию в XML, то необходимы будут инструменты, контролирующие структурную целостность XML данных. Причем, делать это надо как со стороны BPMN 2.0, так и со стороны XPDL 2.2.
Франк Михаэль Крафт (Framk Michael Frank), Success with BPMN 2.0 отмечает, что большим плюсом BPMN 2.0 является возможность изображения как сильно-, так и слабосвязанных процессов. Сильно связанным является процесс, в котором возможность регистрации клиентского заказа зависит от наличия утвержденной цены на продукцию. Слабосвязанный процесс – это клиент регистрирует заказ в любое время. В первом случае шаги процесса объединяются в один пул. Слабосвязанные процессы моделируются сквозь пулы как совместная работа или как хореография. Такое деление – на сильно- и слабосвязанные процессы – оказывает решающее влияние на успех. И это вопрос не столько разработки, сколько бизнеса, поскольку от него зависит гибкость компании.
А вот мнение Макса Пачера (Maks J. Pucher), основателя и главного архитектора ISIS Papyrus Software не такое радужное. В своей статье BPMN 2.0 - A Step Sideways! Он пишет, что несколько дезориентирован будущим стандартом. Он считает, что дополнения, сделанные в стандарте, делают модели очень неоднозначными. «Activity» может представлять любое количество различных функций, и новые типы событий недостаточно детализируют то, как они взаимодействуют в потоке. Там все еще нет артефактов, атрибутов и моделирования состояний и нет бизнес-правил. Обещанное UML-подобное моделирование данных, похоже, тоже отсутствует. Т.е. модели в BPMN 2.0 нельзя будет взять как есть, а необходимо будет перекодирование в BPEL+Java. Т.е. нет никакого замкнутого цикла («roundtrip») и вовлечения пользователей («user empowerment»). Весь входящий и исходящий контент и артефакты по-прежнему придется программировать. Правда, дальше выясняется, что автор вообще противник диаграмм и считает ущербным не столько BPMN 2.0, но и подход к BPM на основе диаграмм («flowcharting BPM approach») в целом.
Это еще раз доказывает, что единого мнения по поводу будущего стандарта не существует (да и не может существовать), поскольку выбирая один путь развития, непременно остаются в стороне интересы другого «лагеря». Остается только надеяться, что если стандарт будет принят такими крупными BPM-вендорами, как IBM, SAP, Oracle, TIBCO, Appian и т.д., то остальное сообщество «подтянется». Лучшего-то пока не придумали…
=WJ
>> Комментарии (всего 2)Ожидания заказчиков и бизнес-процессы
Отвечая на вопрос «Что вы ожидаете от BPM» в числе прочих ожиданий в первых же строках обязательно будет упомянуто «повышение удовлетворенности заказчика». Казалось бы, как все замечательно, как мы заботимся о своих заказчиках! Но всегда ли это так на самом деле? Сталкиваясь с неграмотно организованными сервисами различных организаций, в которые мне приходится обращаться в обычной жизни, я часто задумываюсь о том, почему мне приходится тратить уйму времени там, где вопрос может быть решен в течение нескольких минут. Возможно, это у меня такие завышенные требования, а другим это кажется вполне нормальным? Но оказывается, что я не одинока в своих ожиданиях. Читаю заметку Дерека Миерса (Derek Miers), шефа BPM-Focus, и меня не оставляет ощущение, что он просто читает мои мысли. Вот о чем речь:
Обратившись в службу Adobe с намерением получить продукт под названием ConnectPro, после разговора с тремя людьми из службы техподдержки Adobe, Дерек «отправлен» в клиентскую службу (Customer Service). Прослушав в течение 30 минут музыкальную заставку сомнительного качества (вам это не кажется знакомым?), он, наконец, дождался ответа лица, заявившего ему, что он должен обратится к специальному агенту… после чего его соединили с супервизором клиентской службы, который сказал ему… что он должен связаться со службой техподдержки! «И вот, спустя еще 30 минут, я снова слушаю ужасный джаз».
Дальше Дереку предстояло убедиться, что партнер, через которого происходит покупка, правильно оформил все надлежащим образом… Представьте себе, в каком состоянии он находился после 71 минуты общения!
Поможет ли в данном случае волшебная таблетка под названием BPM? Сомнительно…
Принимаясь за BPM-инициативы, компания, как правило, озабочена больше своими внутренними проблемами, чем реальными ожиданиями заказчика. Хотя многие при этом и говорят, что их процессы ориентированы на заказчика, на деле же они направлены исключительно на повышение эффективности внутри компании. Несомненно, косвенным образом подобные изменения отражаются на заказчике, но всегда ли положительно? Ведь в приведенном примере сотрудники Adobe наверняка освобождены от лишних действий, связанных с решением проблемы заказчика. Но самого заказчика, похоже, такая «забота» не устраивает.
Что получается. С одной стороны, повышая внутреннюю эффективность, компания получает экономию средств за счет экономии рабочего времени сотрудников. Но с другой стороны, разочарованный заказчик – потеря средств (не говоря о том, что свое недовольство он непременно выскажет десятку своих знакомых и коллег). При таком подходе самой эффективной внутренней экономией будет автоответчик, сообщающий, что «мы ничем не можем Вам помочь». Дешево, а с точки зрения удовлетворенности заказчика ничем не хуже.
=WJ
>> Комментарии (всего 0)