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


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

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


     
Возвращаясь к теме roundtrip

Литература:

Автор: Bruce Silver

Оригинал статьи: Roundtripping Revisited

Извините, данная статья доступна только зарегистрированным пользователям. Войдите в систему или зарегистрируйтесь

Комментарии
#1 Анатолий Белайчук, 10.12.2007 14:09

Чтобы еще больше расширить спектр мнений - тут же на сайте опубликована статья Рашида Хана (Ultimus) "О рекламной шумихе вокруг BPM" (http://bpms.ru/library/articles/hyping/index.html). Еще одно подтверждение тезиса Брюса: вендоры "не врубаются" smile

#2 Андрей Гордиенко, 10.12.2007 17:32

BPEL, по-моему, уже просто устарел. Сегодня он не соответствует тем целям, для которых создавался. Нужно просто найти ему замену. Некий XML-стандарт для отображения графической BPMN-нотации.
Давайте вспомним о том, что BPEL возник раньше BPMN. Тем самым спровацировав постановку телеги впереди лошади. Что такое, по сути, BPEL? Это "ассемблер" для графической нотации. Если в ассемблере можно реализовать не все команды ЯВУ, значит это ассемблер просто никуда не годится. Где это видано, чтобы ЯВУ пытались приспособить под ограничения ассемблера? Видимо, просто пришло время предложить что-то новое вместо BPEL, то, что изначально полностью соответсвует нотации BPMN.
Для чего в принципе нужен BPEL?
а) Для портирования БП в среду другой BPMS
б) Для построения [u]исполнимого[/u] описания БП, причем исполнимого с максимальным быстродействием...
С портированием и сейчас не всё здорово - BPEL, сгенеренный для одной системы далеко не всегда работает в другой. От высокого быстродействия тоже толку мало, если в нем в принципе невозможно полноценно выстроить, например human-to-human взаимодействия. По этой причине я считаю, что XML-спецификацию нужно "подтягивать" к BPMN, а не BPMN к созданной ранее XML-спецификации.

По поводу деления BPMN на "для аналитиков" и "для архитекторов" считаю, что такое деление...
а) должно быть возможным, но не более того
б) граница между первым и вторым должны устанавливаться гибко - в зависимости степени компьютерной грамотности людей, занятых моделированием БП.
Наиболее оптимально с моей точки зрения задание такой границы с помощью системных атрибутов, определяющих права доступа и доступные интерфейсы. При таком решении BPMN "для аналитиков" - это просто верхний уровень описания, из которого скрыты детали технической реализации. В свою очередь новая XML-спецификация должна четко разграничивать унифицированные конструкции от специфических для данной конкретной реализации BPMS. Это как раз для целей портирования. Теоретически XML-спецификация может быть построена с расширяемым синтаксисом (то есть, с самомодифицируемым синтаксисом, наподобие синтаксических расширений в языках .NET).
Исполняющее ядро, которое смогло бы поддерживать всю подобную функциональность, скорее всего, окажется тяжеловесным. Поэтому я не исключаю некоторых компромисных промежуточных решений, в виде ряда ступенек на пути к озвученному. И первую из этих ступенек мы уже наблюдаем - отказ от BPEL в ряде BPM-систем.

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

Отдельно хочу сказать про то, что с моей точки зрения также упущено разработчиками стандартов автоматизированного управления БП. Это стандартизация отношений сущностей, которыми оперирует БП. Это контент, который рассматривается [u]в статике[/u] как совокупность взаимосвязанных объектов - примерно так представляют информацию ECM-системы. Потому что кроме собственно бизнес-процесса имеются еще и объекты, которые нужно иметь возможность быстро находить, когда в этом возникла необходимость, либо анализировать из взаимосвязи. Которые могут быть неявными с точки зрения БП, но явными с точки зрения контента.

И еще про то, чего с моей точки зрения не хватает современным BPM-системам. Им не хватает встроенных стандартных средств статистического анализа. Тех средств, которые способствовали бы массовому применению статистических методов управления качеством, выявления характера отклонений, возможности привязки к отклонениям аппарата принятия решения. И в том числе модифицирующих собственно схему БП. В итоге должна быть сформирована некая [u]самомодифицирующаяся[/u] модель - в рамках формализованных процедур самомодификации (например, 8D из модифицированной методологии "шесть сигм"). Должны быть встроенные средства выстраивания иерархии контролируемых параметров БП. И в конечном итоге - "электронные панели управления". Если бы существовали такие BPM-системы, они смогли бы предложить не просто модуль-кусочек для автоматизации некоторой бизнес-деятельности. Это могло бы быть комплексное завершенное решение, нацеленное не просто на охват некоторой совокупности БП, а на построение модели управления предприятием, включающей эффективные средства анализа и принятия решений.

#3 Анатолий Белайчук, 10.12.2007 18:31

Андрей

XML-стандарт для хранения BPMN уже есть, он называется XPDL. XPDL 2.0 разрабатывался таким образом, чтобы полностью покрывать BPMN 1.0. Стандарт работающий.

"Стандартизацию отношения сущностей" на BPM вешать не надо. Это дело DBMS, которую BPMS не заменяет. Разворачивайте в DBMS или в прикладной системы сущности неограниченно сложные и держите в экземпляре процесса ссылки на них -- вот правильная архитектура.

Статистические методы в BPM-системах присутствуют. (Хотя быть может их и не хватает - тут уж кому что нужно.) Например, в TIBCO Business Studio встроенно моделирование по методу Монте-Карло: рисуете схему процесса, задаете распределение входных параметров (на выбор - нормальное, равномерное, экспоненциальное), запускаете simulation, на выходе получаете распределение выходных параметров, времени исполнения процессов и т.д. Наверное где-то может быть полезным. Можете попробовать - Business Studio бесплатно отдается с сайта tibco.com.

Однако это всего лишь симуляция. Что касается статистического анализа реального исполнения процесса, то я в общем согласен с критикой Рашида Хана (см. комментарий #1 выше): как отделить простой от времени, потраченного на выполение? А уж самомодифицирующаяся модель - это, прошу прощения, чистая маниловщина. Адекватно реализовать в BPM-системе процесс as-is, поддерживать его в актуальном состоянии, убрать вопиющие неоптимальности - да уже это будет подвигом и замечательным результатом по критериям бизнеса. В смысле - бабок принесет немеряно smile

#4 Юлия Вагнер, 10.12.2007 19:03

Андрей
Иерархия контролируемых параметров - это отдельная песня. Как Вы думаете, сколько параметров РЕАЛЬНО способен контролировать человек? Не просто любоваться, а контролировать и управлять. Да не больше четырех-пяти. Все остальное - это потешить тщеславие: "вот, у меня есть". Строить иерархии из пяти показателей?
Можно возразить: в BPM заложить математические модели обработки этих параметров. Никто не мешает реализовать это в BPMS, в конце концов в другой системе и подцепить ее к BPMS, но зачем? Следующий шаг - стандартные процессы?

#5 Alexander Samarin, 18.12.2007 22:36

Брюс прав о том, что BPEL дожен генериться автоматически (как PostScript во многих системах). Intalio довольно успешно использует этот подход.

Исторически, многие производители ПО предлагают бизнес моделирование и реализацию моделей как отдельные продукты. Но тенденция (Intalio, SAP) -- это единая среда (часто, Eclipse), которая используется совместно (а в идеальном случае и одновременно) аналитиками и разработчиками.

Я, например, создаю в BPMN (Intalio) исполняемые бизнес процессы итеративно. Каждая итерация -- это Blackboxing, Structuring, Re-construction, Instrumentation -- требует опыт и аналитика и разработчика.

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

Насчет "чего ... не хватает современным BPM-системам" -- я бы хотел работать одновременно со следующими артефактами:

• Added-value chain
• Macro-process
• Events
• Process (coordination of activities)
• Activities (human and automatic)
• Rules (business)
• Rules (routing)
• Data objects -- minimum as XSD
• Documents
• Services (interactive services, solution services, functional services, etc.) -- minimum as WSDL
• Roles
• KPI and traceability
• GUI layouts

AS

#6 Максим Косенко, 19.12.2007 14:54

Вообще тема странная. Я даже не очень понимаю в принципе зачем нужен клиенту BPEL.

Вот Андрей сказал, для
а)портирования
б)ипсолнения и производительности.

Ну пункт А под ОЧЕНЬ большим сомнением, так как портирование это вопрос не только того насколько дотошно поддерживают стандарт разные системы, а и то, что часто портирование одной системы это просто достаточно серьезная смена IT части в компании. А тогда ценность возможности перетащить описания процессов мала, так как в новой инфраструктуре все это однозначно и не заработает и вообще мало пригодится.

Пункт Б - тоже. Очевидно что BPMN позволяет специфицировать расширенными аттрибутами модель и в принципе можно явно исполнять её. Вопрос как это делают совершенно не касается клиента. Для импорта/экспорта вполне пригоден XPDL. В чем хранить модель - опять-таки не касается клиента. Другое дело, что BPMN не описывает все что необходимо в самодостаточной системе. Но нужен ли для этого вообще стандарт - большой вопрос. Да, стандарт на нотацию, на принципы построения, на графическое отображение и на импорт/экспорт быть должен. Он и есть. А вот стандарт на исполнение...

Вопрос производительности мне кажется вообще не в тему. Никакой стандарт описания не поможет сделать производительность/масштабируемость bpms системы лучше. Это исключительно вопрос способностей и целей вендора.

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

#7 Анатолий Белайчук, 25.12.2007 17:56

Коллеги

Предлагаю продолжить дискуссию в обсуждении статьи "семь заблуждений" - в известном смысле, она продолжает тему данной статьи.

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

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