Business Process Management можно перевести как «оперирование бизнес-процессами» или автоматизация управления бизнесом, это новое направление в компьютинге возникло на границе XX и XXI веков и сегодня стало одним из наиболее обсуждаемых. Оно появилось из-за желания преодолеть разрыв между деятельностью людей, управляющих бизнесом, и теми услугами, которые предоставляются им информационными подразделениями предприятий. BPM представляет собой развитие workflow и Enterprise Application Integration (EAI), но конечная цель заключается в создании технологии будущего, которую с подачи Gartner стали называть Business Activity Monitoring (BAM). По замыслу, BAM позволит с использованием средств моделирования наблюдать за бизнес-процессами и управлять ими в режиме реального времени, то есть, обнаруживать тенденции и изменения и оперативно реагировать на них. За недолгий (примерно пятилетний) эволюционный период участники рынка, складывающегося вокруг Web-сервисов, успели заметно консолидироваться и сформировали два взаимодополняющих подхода к моделированю: нотация BPMN и язык BPEL. 

С наступлением нового века начали заметно сдавать свои позиции строгость и определенность компьютинга, ставшие привычными за десятилетия его существования. В дополнение к таким понятным «правильным вещам», как микропроцессор, операционная система, язык программирования, СУБД и сервер приложений появились плохо (а зачастую - противоречиво) определенные Web-сервисы, сервис-ориентированные архитектуры SOA, среды распределенных вычислений grid, языки описания и моделирования бизнес-процессов. Нынешнюю ситуацию так и тянет назвать «смутным временем». Она отягощена и проблемами сложности, возникающими на всех уровнях компьютинга - от микропроцессоров до корпоративных систем. А это обуславливает необходимость в новых математических подходах, кибернетических методах управления, работе с неструктурированными данными и даже в управлении знаниями.

Следует говорить о кризисе компьютинга, как примерно лет 100 лет назад говорили о кризисе физики. Последний был успешно преодолен, причем положительные и отрицательные последствия этого преодоления во многом определили лицо XX века. Если продолжить аналогию, нынешнее состояние компьютинга можно сравнить с физикой в дореляционный период, а его концептуальную основу, состоящую из схемы фон-Неймана и теории передачи данных Шеннона, - с законами Ньютона.

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

Компьютеры захватывают все новые и новые области, не «расчетные» по своей природе. Как тут не вспомнить удивительную прозорливость разработчиков из Digital Equipment Corporation, которые в начале шестидесятых предусмотрительно не стали называть свои изделия компьютерами, а предпочли именовать их программируемыми цифровыми процессорами (PDP - Programmable Digital Processor).

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

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

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

Разумеется, из слабой связанности не следует неопределенность наподобие недетерминированности микромира, объясняемой квантовой теорией. В компьютинге все остается вполне детерминированным, но сегодня он обретает некоторые черты «странности», свойственные миру элементарных частиц. В XXI веке компьютинг с очевидностью нуждается в новых работах, сопоставимых по уровню с трудами фон-Неймана, Винера, Шеннона и способных объяснить эти странности. Однако специфика компьютинга как синтезирующего направления (в отличие от физики) такова, что сначала следует «создать природу», а уж потом ее исследовать.

«Созданием природы» заняты малые и большие компании, делающие бизнес на компьютинге, что придает этому процессу специфический характер, вносит в него передержки, ошибки и даже злоупотребления. Поэтому так трудно отфильтровать подлинные ценности от мнимых. Также преувеличивается значимость отдельных вещей, что теперь в английском языке принято называть hype. Некоторые работающие в России компании предлагают переводить этот термин как «ажиотаж» или «ажиотажное предвосхищение», но в моем представлении любой ажиотаж хоть в какой-то мере объективен, порожден спросом на нечто реально существующее, а hype (или хайп) является просто искусственно раздутой маркетинговой шумихой вокруг того, что лишь может появиться, то есть пусканием пыли в глаза.

Происхождение BPM

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

И еще одно, скорее всего неслучайное, совпадение с тем, что когда-то делалось в DEC. В определении BPM упоминается «реальное время», то есть синхронность работы информационной системы с процессами во внешнем мире. В этом кроется существенное отличие BPM от существующих систем, которые, несмотря на множество интерактивных средств, остаются пакетными. Реальное время присуще лишь управлению технологическими процессами. Создававшиеся в DEC процессоры берут начало от Whirlwind - первой машины, предназначенной для работы в режиме реального времени.

Недолгая, менее чем десятилетняя, но бурная история BPM настолько противоречива, что трудно установить ее достоверную точку отсчета. С некоторым опозданием, в 2004 году, BPM оказалось в центре внимания лидеров отрасли, таких как IBM, Oracle, Microsoft и BEA. Но начиналось все в конце 90-х с деятельности небольших компаний Vitria и Intalio, к которым затем подключилась Collaxa, купленная минувшим летом Oracle. Это - генезис с позиций бизнеса. С точки зрения технологических предпосылок, BPM в его нынешнем виде является еще и объединением Web-сервисов и SOA с управлением потоками работ workflow, что наиболее ярко проявляется в наиболее популярном языке описания бизнес-процессов BPEL (Business Process Exchange Language).

Иногда отцом BPM называют Дэйла Скина, основателя и технического руководителя Vitria Technology. Ранее он создал компанию Teknekron Software Systems, известную теперь как Tibco и являющуюся одной из ведущих фирм в области интеграции приложений. В мае 2001 года Скин был удостоен за свои заслуги звания «Выдающийся выпускник университета Беркли». Чтобы оценить уровень награды, стоит вспомнить, что прежде она присваивалась Стиву Возняку и Биллу Джою.

Именно Скина считают изобретателем идеи распределенных коммуникаций, основанных на принципах публикации и подписки (publish-and-subscribe communications), на которых и базируются слабосвязанные системы. Ему принадлежат следующие слова: «Я думаю, что мы переживаем исторический момент. Web изменил все. Буквально мгновенно мы получили технологии, необходимые для создания всепроникающей (ubiquitous) инфраструктуры: TCP/IP, Web и Web-сервисы, да плюс к тому еще и программное обеспечение с открытыми кодами. По своим возможностям эти новые средства оставляют далеко позади технологии CORBA.

Наиболее ярким представителем направления workflow, также претендующего на роль «родителя» BPM, является Йон Пайк, технический руководитель компании Staffware. Он называет себя традиционалистом, поэтому считает BPM эволюцией workflow, а не революцией. Пайк говорит: «Я занимаюсь программным обеспечением с 1975 года, и всегда считал, что в той или иной форме мы воплощаем в продуктах бизнес-процессы. Я считаю, что BPM есть ни что иное, как подход workflow, реализованный другими с помощью других инструментов».

Нельзя не выделить особо того, что сделано для становления BPM компанией Intalio и созданной под ее патронажем организацией BPMI (Business Process management Initiative). Менее чем за четыре года они сумели привлечь к BPM активное общественное внимание, но в последующем с ними произошло то, что и должно было произойти: «большие» успешно ассимилировали идеи «малых», оставив им собирать крохи. Сейчас то же самое происходит в связи с SOA.

Сегодня, когда о сервис-ориентированных архитектурах не говорит только очень ленивый, кто-нибудь может назвать имена пионеров? Так вот, победный марш BPM начался с того, что в 1999 году Исмаэль Халими создал компанию Intalio в надежде реализовать чрезвычайно интересную и продуктивную идею математика Ассафа Аркина, работающего ныне в его компании.

Аркина открыто называют гением. Он сумел объединить хорошо известный в России математический аппарат сетей Петри с совсем неизвестными пи-исчислениями (Pi Calculus), разработанными английским математиком Робином Милнером, и создать на их базе язык моделирования бизнес-процессов Business Process Modeling Language (BPML). Обратите внимание на слово «моделирование»: здесь буква «M» означает именно Modeling, а не Management или Mark-up, как часто пишут, и это существенно.

Задуманное в Intalio/BPMI моделирование бизнес-процессов явно опережало свое время, а подход авторов BPEL оказался более прагматичным. Он не претендовал на автоматизацию бизнес-процессов и предусматривал лишь более эффективную оркестровку сервисов, связывающих эти процессы.

Коль скоро сравниваются управление бизнес-процессами в режиме реального времени с управлением технологическими объектами, справедливо напомнить, как внедрялось управление технологическими процессами (АСУ ТП). Обычно АСУ ТП, создаваемые в 70-е и 80-е годы, состояли из двух подсистем: информационной и управляющей. Информационная выполняла довольно рутинную функцию - собирала данные об объекте управления и выдавала их в цифровой форме в управляющую подсистему и персоналу операторов.

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

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

Язык XML. Он освободил BPM от необходимости в сложном взаимодействии с источниками данных. Наличие таких стандартов, как XPATH и XSLT, позволило превратить разрозненные массивы данных в единообразный поток, удобный для восприятия и обработки.

ПО промежуточного слоя для взаимодействия между бизнесами (B2B Middleware). Оно основано на стандартах, подобных ebXML, позволяет создать гомогенную среду для взаимодействия между бизнесами. При его отсутствии производителям пришлось бы специальным образом согласовывать различные протоколы.

Интеграция корпоративных приложений (Enterprise Application Integration EAI). Хотя как отдельное направление EAI существует лишь с середины 90-х годов, оно является старейшей частью этого списка. Его роль, так же как B2B Middleware, состоит в создании однородной среды.

Web-сервисы. Это наиболее новый компонент, который позволяет организовать систему, состоящую из слабо связанных приложений.

BPM - третья волна управления бизнес-процессами

Управление бизнес-процессами нуждается не столько в технологической поддержке, сколько в обосновании с позиций бизнеса. Не подлежит сомнению, что самыми яркими пропагандистами BPM от бизнеса стали Говард Смит и Питер Фингар, авторы книги-бестселлера Business Process Management: The Third Wave. Правда, их деятельность трудно оценить однозначно. С одной стороны, они - прекрасные визионеры и евангелисты новых технологий, с другой - явные создатели хайпа вокруг BPM.

До очевидной сегодня победы BPEL над BPML они отождествляли BPM только с языком моделирования бизнес-процессов, яростно отвергая все остальное, особенно workflow. Однако, почувствовав ослабление интереса к созданной ими волне, Смит и Фингар быстро переключились с пропаганды BPML на пропаганду BPM в целом. Дальнейшее развитие их взглядов отражено в недавно изданной книге «Дело не в ИТ, а в бизнес-процессах» (IT Doesn't Matter-Business Processes Do), в которой дается критический анализ нашумевшей в прошлом году статьи Николаса Карра, опубликованной в журнале Hayward Business Review.

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

Рассуждения о «третьей волне» Смит и Фингар начинают с констатации того разочаровывающего факта, что на протяжении десятилетий (буквально с 50-х годов) от компьютеров ожидают больше, чем от них реально можно получить. Сначала доминировала мифологизация мыслительных способностей машин, потом наделялись избыточными возможностями информационные системы для бизнеса (MIS) и т.д. Но даже сегодня, несмотря на действительно фантастический потенциал имеющихся технологий, компьютеры остаются все тем же, чем они всегда и были, а именно - сложными инструментами для оперирования данными.

С годами менялась лишь количественная сторона, но не качественная, а в результате сложилось и продолжает существовать устойчивое разделение: «бизнес - отдельно, информационные системы - отдельно». Это разделение пытаются преодолеть самыми разными способами, например с помощью ITSM, но два мира по-прежнему существуют раздельно.

Чтобы преодолеть пропасть между возможностями информационных технологий и потребностями бизнеса, необходимо признать приоритет управленцев-профессионалов и подчинить им работу информационных систем. Смит и Фингар говорят: «Следует расставить акценты естественным образом. Подчиненность бизнес-процессов следует вернуть людям из бизнеса». Для этого, прежде всего, следует отказаться от доминировавшей до последнего времени парадигмы обработки данных (data processing) в пользу парадигмы обработки процессов (process processing).

В рамках традиционной датацентричной парадигмы люди из бизнеса не могут непосредственно включаться в контур управления. Свое представление о том, как может выглядеть участие людей из бизнеса, Смит и Фингар иллюстрируют следующим примером. До 2000 года умами властвовали успех Internet-компаний. Достижение фирмой Amazon первенства в книжной торговле через Сеть даже привело к появлению глагола амазонировать (to amazone), и казалось, что еще немного, и весь бизнес будет амазонирован.

Сейчас на первый план выходит положительный опыт General Electric, и, соответственно, появился глагол «to generalelectrify». GE занимается автоматизацией существующих бизнес-процессов, с тем чтобы создать для лиц, принимающих решения, необходимый набор инструментов в виде персонализированного цифрового пульта управления (personalized digital cockpit), который позволяет работать в режиме реального времени. Этот подход к автоматизации Смит и Фингар назвали третьей волной BPM.

Первой была волна BMP, возникшая в 20-е годы прошлого века под влиянием трудов Фредерика Тейлора в области менеджмента. Эта волна характеризовалась тем, что процессы «вкладывались» в практику работы, не выделялись особым образом, поскольку не могли быть автоматизированы. Вторая волна, возникшая лет 10-15 назад, была связана с реинжинирингом систем и пакетными приложениями, такими как ERP, CRM и т.д. Третья волна основывается на предположении о возможности создания автоматизированных систем, построенных на принципах обратной связи, и предполагает слияние отдельных технологий управления в единое целое.

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

Бизнес-процессы - управление и моделирование

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

Примерно тогда же были созданы методики построения диаграмм потоков данных (Data Flow Diagrams - DFD) и аналогичных им диаграмм потоков управления (Control flow diagrams - CFD). Они основывались на двух подходах: классической теории структурного анализа и теории машин с конечным числом состояний, и объединяли их в единое целое. Развитием этих методов стали функциональные потоковые диаграммы (Functional Flow Block Diagram - FFBD), включавшие в себя функции предшествования, одновременности, параллельности и альтернативности исполнения процессов.

Диаграммы потоков данных отражают процессы распределения и трансформации данных, а диаграммы потоков управления, аналогичные DFD, выполняют ту же функцию по отношению к потокам управления. Возможны также комбинированные решения DFD/CFD с потоками данных и потоками управления.

Однако наибольшую популярность приобрели диаграммы, изобретенные Генри Грантом в 1917 году, усовершенствованные в пятидесятые годы в исследовательских подразделениях американского военно-морского флота и получившие известность как PERT-диаграммы. В СССР (где их называли «методами сетевого планирования», не афишируя их заокеанское происхождение) они стали особенно популярными в семидесятые годы. Диаграммы Гранта и PERT-диаграммы наиболее успешно применялись для управления проектами. Естественно, они были неплохим подспорьем в условиях плановой экономики, поскольку позволяли оптимизировать план с использованием метода критического пути (Critical Path Method - CPM). По некоторым исследованиям, были созданы свыше 20 некомпьютерных методов моделирования процессов и примерно 350 типов инструментальных средств.

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

Более современные методы моделирования и визуализации бизнес-процессов можно разделить на те, которые появились на свет за несколько лет до Web-сервисов, и основанные непосредственно на Web-сервисах и сервис-ориентированных архитектурах. В последний год начало складываться впечатление, что первые прекратят отдельное существование и продолжат свою жизнь в конвергенции со вторыми. Еще совсем недавно в список актуальных языков для описания моделей входили ebPML, BPML, XLANG, WSFL, BPEL4WS, EDOC, XPDL и UML 2.0, но после укрепления позиций языка BPEL4WS, переименованного в BPEL, все остальные перестали составлять ему серьезную конкуренцию.

Из современных языков моделирования раньше других, в 1994 году, появился язык Unified Modelling Language (UML). Он возник на основании развития множества существовавших на тот момент объектно-ориентрованных нотаций. Наиболее популярными оказались методика моделирования Booch, которую предложил Гради Буч из Rational Software, и OMT, автором которой был Джеймс Рамбау. Объединившись, они создали общий метод моделирования Unified Method, а затем вместе с Айваром Якобсоном развили его до UML.

Версия 0.9 UML появилась в июне 1996 года. В том же году Object Management Group опубликовала свои предложения по этому языку, и они были приняты группой компаний, в том числе DEC, HP, IBM, Microsoft, Oracle, Rational Software, TI и Unisys. Так в 1997 году появился UML 1.0.

Язык UML используется для спецификации, визуализации, конструирования и документирования в процессе разработки объектно-ориентрованных программных систем. Он представляет собой собрание «лучшего инженерного опыта», накопленного в процессе создания сложных систем. С помощью средств UML, называемых диаграммами, можно строить три вида моделей: функциональную, объектную и динамическую. Графическая нотация в UML имеет текстовые эквиваленты в объектно-ориентированных языках программирования, например Java.

Качественно новым шагом в моделировании стало появление нотации Process Modeling Notation (BPMN) «общественной организации» Business Process Management Initiative (BPMI). Совершенно очевидно, что эту организацию создала компания Intalio в качестве своего alter ego для большей свободы при распространении предложенного ею стандарта моделирования BPMN и языка BPML. За действиями BPMI просматривается, прямо скажем, романтическое желание совершить переворот в области моделирования бизнес-процессов. А уж если совсем перейти на революционный язык, в качестве своего катехизиса BPMI/Intalio выбрала пи-исчисление Робина Милнера.

По первоначальному замыслу, на основе BPMN можно было бы создавать BPMS (Business Process Management System) как «единую и единственную среду, обеспечивающую моделирование, интеграцию и выполнение, которая может использоваться в приложении к практически любым бизнес-процессам». Так писали Смит и Фингар в мае 2002 года в Internet World.

На короткий момент показалось, что BPMS могут сыграть ту же роль по отношению к процессам, что Relational Database Management System играет по отношению к данным, - не случайна и аллюзия BPMS и RDBMS в названии. Среда BPMS должна была, по мнению Смита и Фингара, стать машиной для выполнения процессов (engine for processes). В своем подходе к управлению бизнес-процессам BPMI/Intalio отводили пи-исчислению роль, аналогичную роли реляционной модели Эдгара Кодда в RDBMS. Утверждалось, что пи-исчисление является следующим шагом в развитии формальных основ программирования по отношению к лямбда-исчислению(lambda calculus), признаваемому как основа современного программирования. Принципы лямбда-вычислений были предложены в 30-е годы американскими математиками Алонсо Черчем и Стивеном Клайни, работа которых имеет много общего с трудами Курта Гёделя и Алана Тьюринга.

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

Нотация моделирования BPMN

Парадоксально, но достоинства BPMN были признаны создателями языка BPEL, прямого конкурента BPML, и сегодня можно говорить о конвергенции и формирующейся связке BPMN и BPEL. «С высоких позиций» это в определенной степени шаг, но с практической точки зрения - вполне реальный шаг вперед. В мае 2004 года рабочая группа BPMI Notation Working Group после двухлетних усилий выпустила стандарт BPMN 1.0. Его важнейшая цель - дать такую форму представления модели процессов в бизнесе, которая была бы понятна и аналитикам, и разработчикам, и тем, кто станет осуществлять мониторинг бизнес-процессов.

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

Состоящая из четырех этапов технологическая цепочка создания слабосвязанной системы с использованием технологии Web-сервисов и BPMN  могла бы выглядеть следующим образом:

  • проектирование процессов средствами BPMN;
  • моделирование и оптимизация процессов;
  • описание сервисов средствами BPEL;
  • оркестровка сервисов.
Девятиуровневая модель поддержки бизнес-процессов

Рисунок.

Основным инструментом BPMN служит диаграмма бизнес-процессов (Business Process Diagram - BPD), которая строится примерно на тех же принципах, что и блок-схемы и PERT-диаграммы. Полученная в результате модель Business Process Model представляет собой сеть графических объектов, которые изображают действия или работы, связанные потоками управления (см. Рисунок).

Диаграмма BPD имеет два основных достоинства. Во-первых, она проста в использовании и понимании. Применяя ее на начальном уровне сложности, можно найти общий язык с нетехническим персоналом, а это, как известно, было проблемой уровня поиска «философского камня» при разработке информационных систем. Во-вторых, поднимаясь на более высокий уровень сложности описания, можно постепенно подойти к естественному отображению на языке исполнения бизнес-процессов, например к тому же BPEL. Таким образом, процесс разработки приобретает органичный эволюционный характер.

Еще одно достоинство BPMN заключается в том, что ликвидируется фрагментарность разных видов, наблюдаемая при разработке систем. Нотация моделирования может стать объединяющей для таких средств, как UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM и Event-Process Chains (EPC). Кроме того, появляется возможность преодоления разрыва между бизнес-ориентирванной нотацией и ИТ-ориентрованным исполнением.

Графические объекты BPMN, поддерживаются богатым набором атрибутов, которые могут непосредственно отображаться в язык BPEL (точнее - в Business Process Execution Language for Web Services, или BPEL4WS v1.1), превращающийся в стандарт де-факто. А нотация BPMN, потеряв привязанность к языку BPML, активно развивается. До лета 2005 года должна появиться ее версия 1.1, а кроме того, следует ожидать объединения усилий BPMI и OMG, результатом чего может стать консолидация Business Process Diagrams и UML Activity Diagrams.

BPEL в майке лидера

События, которые связаны с языками описания и моделирования бизнес-процессов, обобщенно именуемыми XML BP (XML Business Process Languages), напоминают велосипедную гонку. Вначале из пелатона, состоящего из BPML, XPDL (предложен консорциумом WfMC), BPEL4WS (IBM, Microsoft BEA), XLANG (Microsoft) и WSFL (IBM), вырвались вперед BPML и BPEL4WS, а затем последний стал единоличным лидером. Сравнение с соревнованием не случайно: есть большая вероятность того, что лидер станет победителем, но она никогда не равна 100%.

Язык-лидер чаще всего называют BPEL, хотя в документах OASIS встречается название WS-BPEL, а у IBM, BEA - иногда и BPEL4WS, но в любом случае речь идет о Business Process Execution Language for Web-services. В данный момент BPEL проходит финальную стадию доработки в техническом комитете OASIS BPEL TC. Этот комитет действует под руководством Дианы Джордан (IBM) и Джона Евдемона (Microsoft).

К своему нынешнему виду BPEL эволюционировал из слияния XLANG (языка категории XML BP, созданного в Microsoft на основе пи-исчисления) и разработанного в IBM языка WSFL (также языка категории XML BP, но использующего сети Петри). Позже некоторые дополнения были предложены BEA, а потому и эту компанию включают в число авторов BPEL.

Несмотря на множество родителей, говорят, что язык получился удачный. Показательно, что компания Intalio, построившая свой основной продукт Intalio/n3 на базе собственного языка BPML, планирует перейти на BPEL, добавив в него некоторые недостающие «вещи» из BPML. Для этого Intalio стала членом комитета OASIS BPEL TC.

Что же касается приверженцев workflow, пока Workflow Management Coalition сохраняет поддержку своего языка XPDL, но уже рассматриваются вопросы, связанные с конвергенцией XPDL и BPEL. Целый ряд компаний, прежде всего IBM, активно работают над объединением UML и BPMN. Это должно позволить создать единую метамодель, которая может быть отображена в Java, BPEL или XPDL.

Весной 2004 года IBM и BEA опубликовали совместный документ «BPELJ: BPEL for Java», в котором предложен еще один язык BPELJ, являющийся комбинацией BPEL и Java. Прокламированная цель заключается в том, чтобы приблизить описание процессов к производству программных продуктов. BPELJ позволяет включать в BPEL фрагменты Java-кодов, так называемые Java snippets.

Появление BPELJ вызвало противоречивую реакцию - от активного приятия и умеренного скептицизма до яростного ниспровержения. Скептики назвали BPELJ шагом вперед и шагом назад одновременно. Наиболее агрессивно против BPELJ выступил упоминавшийся выше Говард Смит, который опубликовал критический труд Enough is enough in the field of BPM. В нем он не только доказывает конъюнктурность политики компаний, продвигающих BPELJ, но и критикует отказ от BPML в пользу BPEL. Тем, кто проявляет глубокий интерес к управлению бизнес-процессами, эту работу можно порекомендовать в качестве обязательного чтения.