Эстонский голем beobachterЯ ж и не предлагаю обсудить плюсы и минусы языка описания бизнес-процессов. Напротив, предлагаю обсудить возможность применения методов рефакторинга к уже созданному на этом языке коду. И, поскольку на этом языке описан бизнес-процесс, то и к улучшению бизнес-процессов.
а где можно посмотреть спицификацию и стандарт
Правда, уже устаревшая версия:
ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

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

АБ Vasiliy VladimirovithА чем плох Business Process Execution Language Тем, что в нем не предусмотрены средства для описания шагов бизнес-процесса, выполняемых людьми. Такой вот развесистый bat-файл с приделанным к нему графическим редактором.А можно поинтересоваться, в каком языке описания бизнес-процессов (исполняемых, разымеется) такие средства есть? И если можно, поясните, как Вы себе на практике представляете выполнение иструкций этого языка, описывающих операции, выполняемые людьми.

К сожалению, я знаком с предметом только посредством MS BizTalk Server. Так вот, в нем используется именно BPEL, и нет никаких ограничений по взаимодействию с людьми. Просто между языком и человеком, исполняющим бизнес-процесс, как я понимаю, в любом случае находится какое-то программное обеспечение (иначе просто и быть не может), которое реализует некоторый визуальный интерфейс и функциональность для диалогового взаимодействия. В случае с MS BizTalk Server взаимодейсвтие с людьми осуществляется преимущественно через MS Office InfoPath. Поскольку последняя является программой, то средств взаимодействия с программами в BPEL вполне хватает. Описание визуального интерфейса, его оформление, функциональность, механизмы обращения к данным и т.д. и т.п. закладываются в настраиваемых формах InfoPath, которые могут быть связаны также и друг с другом, образуя некоторую совокупность взаимодействующих форм. В этом смысле четко разграничиваются средства, которыми описывается бизнес-процесс и средства, которыми описываются реакции на шевеления мышкой. Я считаю такой подход вполне оправданным и логичным.

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

beobachterКогда видишь команды While, until в языке описания БП, то невольно напрашивается применение тех же методов. О памяти - представьте, что у вас имеется не оптимальноописанный БП с такими циклами или с элементами компенсации.Дело в том, что "неоптимальные" с точки зрения длины пути вычислений или используемой памяти алгоритмы могут оказаться как раз оптимальными с точки зрения бизнес-процесса. Например, с точки зрения надежности может оказаться существенным продублировать выполнение или контроль некоторых операций. Мне кажется, о рефакторинге говорить тут не приходится. Слишком много критериев, причем, на разных участках одного и того же бизнес-процесса - разные. Некоторые из них завязаны на внешние факторы, которые неспособен учесть никакой рефакторинг.

АБGarya, Вы подняли очень хороший вопрос. Настолько хороший, что жаль обсуждать его в этом топике. Может, откроем новый?Уже открыл... :)

beobachterВедь вы же не будете спорить, что описание БП есть частный случай объектно-ориентированного подхода программирования и для него свойственны те же правила?Будем спорить... :) Бизнес-процесс - это результат проектирования управления некоторой деятельностью. Если IT оперирует детерминированной информацией, которую четко можно измерить (байтами, например) то менеджмент оперирует существенно менее формализованной, эвристической информацией. В книжке, на которуюя я уже неоднократно приводил ссылку , на эту тему есть замечательные слова:
цитата со стр.336Можно с большой уверенностью сделать вывод о том, что в последние десятилетия проблема управляемости предприятий в рыночной экономике решалась с использованием эвристических подходов, сходной по своей природе с методологией, практикуемой алхимиками. Аналогия с методологическими приемами, пришедшими из Средневековья, очевидна:
* эвристический поиск "базовых реактивов" аналогичен декомпозиции задачи управления на квазинезависимые субпроцессы (задачи);
* эвристический поиск "философского камня" подобен поиску процесса (задачи), "размещаемого" на верхнем иерархическом уровне процессов (задач). Например, известно выражение - "бюджетирование как мигический кристалл";
* проведение эвристических экспериментов с "базовыми реактивами" сходно с определением последовательности реализации субпроцессов (решения ранее определенных аналитических задач), т.е. построение иерархии;
* эвристическое увеличение разнообразия "базовых реактивов" напоминает расширение возможностей СУП по информационному обеспечению ЛПР.Примечение: СУП - "система управления предприятием", ЛПР - "лицо, принимающее решения".

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

Приведу пример из булевой алгебры. 2НЕ->ИЛИ->НЕ = И. Это выражение обладает, кроме того, симметрией. Подобных четко обозначенных и неоспоримых правил в данной свере знания множество. Используя эти правила, можно преобразовывать логические схемы из одного вида в другой, получая совершенно идентично работающие схемы при меньшем количестве (или стоимости) составляющих их элементов. Есть критерий оптимизации и есть четкие правила, которыми можно воспользоваться, чтобы попытаться достичь этих критериев, не исказив при этом заранее заданную логику работы.
В менеджменте же ОТСУТСТВУЮТ подобные четко вормулируемые уравнения. То, что в одной ситуации можно трактовать как знак равенства, в другой ситуации так трактовать окажется недопустимо. Слишком много эвристики. Слишком много информации, находящейся за пределами определенности. Тут работает интуиция, а не математическая логика. По крайней мере, пока.

Дополню. Есть такая область IT как BI. Именно она достигла каких-то успехов по выявлению некоторой определенности из неопределенности... Может быть, Вам имеет смысл направить свои усилия в том направлении?

Представьте себе бизнес-процесс, в котором один и тот же документ направляется одновременно на согласование Иванову и Петрову (через блок распараллеливания). А далее стоит анализ - от кого быстрее поступит информация, тот и согласовал - и по его согласованию и идет дальнейшая обработка. Что сделает оптимизатор? Он задастся вопросом "а нафига, собственно, направлять документ на согласование сразу двум сотрудникам?" - уберет из схемы одного из них и оставит одного. Который через неделю после этого заболеет, а документ, который должен был проходить согласование в любом случае в заданные сроки его не пройдет. После чего руководитель обмакнет в скипидар тряпочку и пригласит задницу оптимизатора... :)