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


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

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


     
Обзоры, выпуск 8, 2008 г.

Литература:

Ушел из жизни Гэри Раммлер

Когда я собиралась писать эту заметку, я хотела ограничиться информацией о том, что ушел из жизни еще один идеолог процессного управления, человек, которого можно назвать прародителем Business Performance Management (именно performance, но основой повышения эффективности управления бизнесом он считал процессный подход). Однако, появившаяся в BPTrends статья Пауля Хэрмона (Paul Harmon) с заголовком «Geary A. Rummler» не оставила меня равнодушной, и я, ссылаясь на эту статью, расскажу о нем немного подробнее.

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

В 1990 году Раммлер совместно с Аланом Брэйчем (Alan Brache) выпустили книгу «Improving Performance: How to Manage the White Space on the Organization Chart» - известная теория о белых пятная на функциональной диаграмме.

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

Он рассматривал организацию в трех уровнях – организационный, процессный и исполнительный. И создал матрицу связи (Рис. 1)

 

Цели и измерения

Дизайн и исполнение

Управление

Организационный уровень

Организационные цели и измерения организационного успеха

Организационный дизайн и исполнение

Организационный менеджмент

Процессный уровень

Процессные цели и измерение процессного успеха

Процессный дизайн и исполнение

Процессный менеджмент

Исполнительный уровень

Исполнительные цели и измерение успеха исполнения

Исполнительный дизайн и исполнение

Исполнительный менеджмент

Рис. 1. Трехуровневая структура Раммлера

Дальше Раммлер предложил карту связей, которую теперь принять называть организационной диаграммой (Рис.2)

Рис.2. Карта организации

На верхнем уровне Раммлер рассматривает организацию с точки зрения основной цепочки ценностей: вход – производство – выход. Это 1) процессы, которые представляют и создают продукты и ценности; 2) процессы, которые их производят; 3) процессы, которые их продают и обеспечивают доставку. Деление цепочки ценностей на три уровня – это стартовая точка для детального анализа процессного уровня.

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

Последняя книга «Performance Consulting According to Rummler», вышедшая в 2004 году, может стать настольной книгой для всех, кто серьезно озабочен повышением эффективности своей организации.

 = WJ

>> Комментарии (всего 0)

Кризис может сыграть на руку BPM?

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

Что делать в таких условиях BPM-щикам? Вопрос массовой продажи лицензий на ПО скорее всего отойдет на второй план. А вот умение выявлять и оптимизировать бизнес-процессы – это тот продукт, который может пользоваться большим спросом.

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

По его мнению, одна из самых трудных задач, стоящих перед BPM-командами – определить, решение каких процессных проблем принесет максимальный ROI. Компании, имеющие сильную процессную команду, могут снизить издержки на 10-30%. Но даже несмотря на то, что изменения будут направлены на достижение быстрого результата, они смогут обеспечить неплохую платформу для последующего развития.

Такого же мнения придерживаются Rod Favaron (председатель и CEO) и Phil Gilbert, (CTO и президент) Lombardi. Phil Gilbert тоже считает, что улучшив сейчас свои ключевые процессы, компании получат успех, когда ситуация стабилизируется. В ближайшем будущем он видит больше перспектив в В2В процессах, т.к. это увеличивает число точек соприкосновения с клиентами. Кроме того, это – долгосрочный рецепт для BPM.

 =WJ 

>> Комментарии (всего 2)

Не ставьте знак равенства между BPM и BPEL

По общему мнению, BPEL и BPMN – два наиболее перспективных стандарта в области BPM.

Что касается BPEL, то отдельные вендоры столь сильно преуспели в его популяризации, что некоторые стали считать его практически синонимом BPM: говорим BPM, подразумеваем BPEL. Хотя аналитики всегда предупреждали: «beepel is not for people».

С BPMN ситуация менее ангажированная, но и тут не обходится без завышенных ожиданий: реализация этого стандарта в движках существующих BPMS пока далека от полноты.

За последнюю пару недель появилось сразу несколько интересных статей авторитетных авторов, без прикрас рассматривающих возможности BPMN и BPEL:

Why BPEL is not the holy grail for BPM, Pierre Vigneras.

Автор констатирует, что даже сторонники BPEL признают, что он с трудом воспринимается бизнес-пользователями, BPMN в этом отношении явно предпочтительнее.

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

Если программист продолжает настаивать на своем видении, то это приводит к тому, что программист и бизнес-аналитик оперируют разными артефактами, а в итоге – к драматичному разрыву между бизнесом и ИТ, который сегодня осознан как фундаментальная проблема. И для решения которой, в том числе, собственно и был предложен BPM. Таким образом, логически вытекает, что BPEL не может решить все проблемы BPM.

Отсюда путь, который выбрали несколько вендоров: моделирование в BPMN и автоматическая трансляция в BPEL, рассматриваемый при этом как исполняемый код. В качестве примера такого подхода в статье приводится Intalio BPMS. Однако, после многочисленных попыток, сегодня можно констатировать, что в общем виде эта задача не решается. С одной стороны, приходится ограничивать использование BPMN некоторым подмножеством. А с другой, для многих технических подробностей процесса, относящихся к его исполнению, нет места в BPMN – они должны быть внесены в BPEL. Последний факт делает весьма проблематичным «round-trip» – замкнутый цикл разработки, вовлекающий и аналитика, и разработчика.

Проще говоря, BPMN в BPEL автоматически транслировать можно, но только один раз. После этого у аналитика и программиста на руках оказываются два разных артефакта, и мы снова возвращаемся к тому, от чего хотели уйти.

Why All This Matters, Ismael Ghalimi (Intalio).

Поскольку в первой статье упоминается Intalio в качестве апологета генерации BPEL из BPMN, уместно дать ссылку на статью, в которой Исмаэль Галими делает экскурс в историю появления BPEL и подробно объясняет, чем лично его привлекает BPEL, попутно не слишком лестно отзываясь о вендорах, не разделяющих его пристрастия. Не вдаваясь, впрочем, в проблематику BPMN->BPEL генерации.

BPMN-BPEL in Perspective, BPM Standards in Perspective, Bruce Silver.

В своем отклике Брюс замечает, что и BPMN, и BPEL не идеальны. Но BPMN пользуется успехом несмотря на его недостатки, в то время как недостатки BPEL по факту ограничивают его применение в основном областью интеграции и SOA.

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

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

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

В качестве ремарки к заметке Исмаэля Галими Брюс напоминает, что недавно в сторонники непосредственного исполнения BPMN движком записались Oracle и SAP (мы об этом писали), использование BPEL они ограничивают областью SOA/интеграции. Действительно, эти два тяжеловеса способны решить исход спора «за» и «против» BPEL одним фактом своего предпочтения, что называется, не прибегая к аргументам.

BPEL-Grail, Keith Swenson (Fujitsu).

Кейт Свенсон, представляющий еще одного BPM-вендора, делится своим наблюдением, что фанаты BPEL делают три предположения:

  1. процессы проектируют программисты
  2. шаги процесса сводятся к отправке, приему или трансформации XML-данных
  3. любой стандарт лучше отсутствия стандарта

Предположения 1 и 2 истинны применительно к задачам интеграции (EAI). Что касается предположения 3, то при огромном числе журнальных «доказательств» правильности BPEL некоторые начинают считать, что любой, кто не поддерживает BPEL, либо слишком ленив, либо пытается раздробить рынок. На деле же мир процессов сложнее, чем кажется. Не упускайте из виду собственных требований: если BPEL им удовлетворяет – отлично, но не принимайте априори, что он годится везде и всюду.

=АБ

>> Комментарии (всего 5)

The Forrester Wave™: Integration-Centric Business Process Management Suites, Q4 2008

6 октября 2008 г. 

автор Ken Vollmer

Forrester проводил исследование Integration-Centric  BPMS в следующих четырех областях:  enterprise application integration (EAI), business-to-business interactions (B2B), business process management (BPM),  service-oriented architecture (SOA). Лидерами признаны Software AG, IBM, TIBCO Software, Vitria Technology, Oracle , SAP и Cordys Software.

Неплохие показатели у Microsoft, Sterling Commerce, и Sun Microsystems, но они имеют ограничения в BPM функциональности.

Функциональность IC-BPMS:

BPM

Обеспечивают поддержку BPM, используя BPMN и BPEL, переводя нотацию в исполняемый код через XPDL. Поддерживают оркестровку, исполнение, мониторинг и оптимизацию.

B2B, EAI и SOA

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

Разработка приложений

Инструментарий для создания композитных приложений и динамических бизнес-приложений – это еще одна сильная сторона IC-BPMS. Они включают в себя model-driven разработку, встроенную в IDE (integrated development environments), поддержку SOA и движки бизнес-правил.

Тенденции развития рынка IC-BPMS

С одной стороны, на рынке IC-BPMS наблюдается объединение вендоров, ярким примером чего является приобретение Oracle BEA Systems, и немногим раньше приобретение Software AG webMethods. С другой стороны, каждый вендор старается предложить новые возможности продукта, которые будут отличать его от других вендоров.  Это могут быть, к примеру, имитационное моделирование, выявление процессов, управление событиями, complex event processing (CEP), движки бизнес-правил.

Итак, что собой представляют сейчас IC-BPMS (информация о продуктах и критерии отбора):

 

Критерии отбора вендоров

  • Продукты представляют  собой наиболее законченные интеграционные решения и возможность управления комплексной интеграцией, оркестровкой взаимодействий людей, приложений, back-end-систем и внешних бизнес-партнеров
  • Имеют значительную долю рынка в этом секторе
  • Версия продукта была выпущена не позднее 1 мая 2008 года

На следующей диаграмме:

Software AG, IBM, TIBCO, Vitria, Oracle, SAP, Cordys lead – предлагают полноценные решения во всех областях заявленной функциональности

Microsoft, Sterling Commerce,  Sun Microsystems - эти вендоры хороши во всем, кроме BPM-функциональности

Oracle’s BEA WebLogic Integration имеет весомую функциональность, однако пока не ясен путь его дальнейшего развития.

 

И еще сравнение по пятибалльной шкале от 0 (слабые) до 5 (сильные):

 

Лидеры рынка:

  • Software AG -приобрел webMethods в 2007 году и усилил его мощным CentraSite репозиторием, разрабатываемым совместно SAG и Fujitsu
  • IBM - основные продукты в его портфолио - WebSphere Dynamic Process Edition (включающий в себя  WebSphere Business Modeler, WebSphere Business Services Fabric, WebSphere Process Server, WebSphere Business Monitor) и WebSphere Service Registry and Repository. В течение года IBM сделал несколько ключевых приобретений, связанных с BPM возможностями, таких, к примеру, как Webify и AptSoft, в надежде укрепить свои позиции
  • TIBCO Software - его ActiveMatrix BusinessWorks  достаточно известный и популярный IC-BPMS продукт. Стоит также отменить, что TIBCO iProcess является одним из лидеров human-centric BPM
  • Vitria Technology - предлагает уникальную комбинацию EAI, BPM и SOA поверх гибкого Web 2.0 фреймворка
  • Oracle - усилил свои позиции, которые он занимал как один из лидеров рынка SOA,  благодаря приобретению BEA и унаследовав такие ключевые продукты, как ESB и репозиторий
  • SAP - Net Weaver  попал в этот отчет благодаря усилению SOA возможностей
  • Cordys Software - занимает лидерские позиции по всем позициям - EAI, BPM, B2B и SOA
  • Microsoft - Microsoft BizTalk хорош в EAI и поддержке B2B, но он абсолютно не поддерживает BPM «из коробки».

Полную версию отчета можно скачать здесь: http://www.vitria.com/M3O/wave.php

 =WJ

>> Комментарии (всего 0)

Отрасль BPM застряла на ничейной полосе?

Представляем вашему вниманию размышления Рашида Хана (Rashid Khan) - ветерана отрасли BPM с 14-летним стажем, основателя и президента консалтинговой компании Leadership BPM, в прошлом основателя и CEO известного BPM-вендора Ultimus Inc. И название, и тональность заметки на его блоге вызывают ассоциации со знаменитым романом «На западном фронте без перемен» и с мемуарами отставных генералов. Вместо маневренной и победоносной войны «солдаты BPM» получили войну позиционную, окопную, затяжную. Вроде и со стратегией все в порядке, и с тактикой – а победа не дается. Впрочем, Рашид Хан остается оптимистом и в своей заметке ищет «танки», которые смогут принести перелом в войне за умы и за кошельки бизнес-пользователей.

За свои 14 лет в отрасли BPM/workflow я обнаружил три константы. Во-первых, все прогнозы рынка BPM, составляемые уважаемыми фирмами, оценивают размер рынка в диапазоне от 1 до 3 миллиардов долларов, а темп роста в диапазоне от 10 до 20 процентов в год. Даже если взять консервативную оценку и предположить, что рынок составлял 1 миллиард в 1998 году, а рост составляет 15%, то сегодня рынок должен был бы быть 4 миллиарда минимум. Между тем самые последние прогнозы продолжают давать оценку в районе 2 миллиардов. Так куда же улетучивается весь этот рост? Во-вторых, любой BPM-вендор или аналитик способен привести множество реальных кейсов внедрения BPM, демонстрирующих замечательный ROI и выигрыш производительности. И высшему руководству довольно легко понять, как BPM способен обеспечивать такие результаты. Вместе с тем, проникновение BPM в организации все еще мало и я рискну сказать, что автоматизировано менее 10% процессов, несмотря на все примеры, доказывающие ROI и производительность. В третьих, каждый год BPM-вендоры заявляют внушительный рост и публикуют список новых клиентов. Однако большинство поставщиков «чистого» BPM (pure-play vendors) – относительно небольшие компании и ни одной не удалось выйти на фондовый рынок, несмотря на заявленный рост и тот факт, что многие из них привлекли десятки миллионов долларов венчурного капитала.

Мне кажется, что отрасль BPM застряла на ничейной полосе. Поставщики «чистого» BPM не обладают ни гибкостью по-настоящему малых компаний, ни ресурсами или ударной силой больших. Хотя BPM обладает великолепным потенциалом, трудности, с которым сталкиваются эти поставщики, весьма значительны, что делает рост схожим с продвижением в окопной войне. Во-первых, BPM выглядит очаровательно, но это не так уж просто. Причина в том, что человеческие существа делают свою работу очень сложными способами. Разработать софт, который бы обслуживал все эти способы, нелегко. «Человеческий интерфейс» BPM сложен и труден в реализации. Во-вторых, ИТ-окружение, в котором должен цвести BPM, очень сложно, изменчиво и находится в постоянном движении. BPM не может быть успешным без гладкой интеграции с остальной ИТ-инфраструктурой. «Программный интерфейс» BPM сложен и труден в реализации. В третьих, с возрастанием размера и значимости проекта BPM решение о покупке поднимается на уровень высшего руководства. Высшие руководители предпочитают иметь дело с крупными поставщиками платформ, такими как IBM, SAP, Microsoft и Oracle, и это предпочтение ограничивает возможности поставщиков «чистого» BPM. «Маркетинговый интерфейс» BPM сложен и труден в реализации.

Я полагаю, что поставщики «чистого» BPM застряли на ничейной полосе из-за трудностей в реализации «человеческого интерфейса», «программного интерфейса» и «маркетингового интерфейса». Однако я по-прежнему оптимист в оценке рынка и его перспектив. Я оптимист, потому что предельная концентрация и технологические перемены, как правило, играют на руку меньшим и более подвижным компаниям. Мы снова проходим сквозь период технологических перемен, которыми могут воспользоваться поставщики «чистого» BPM. Web 2.0 предоставляет им отличную возможность атаковать трудности «человеческого интерфейса». Растущая зрелость SOA предоставляет отличную возможность справиться с трудностями «программного интерфейса». И наконец, время, неустанная концентрация и постоянство дают возможность справиться с «маркетинговыми трудностями».

Оригинал статьи: Is the BPM Industry stuck in no-man’s land?

=АБ

>> Комментарии (всего 0)

Конференция по BPM: подводим итоги

Тема управления бизнес-процессами сегодня интересует многих.

Кто-то внедряет системы менеджмента качества, все эти TQM, Kaizen, Six Sigma, Lean Production, ISO 9000 и т.д., которые основаны на процессном подходе.

Другие считают, что путь к успеху лежит через реинжиниринг бизнес-процессов и активно продвигают риторику Хаммера и Девенпорта.

Третьи пришли к процессам из BSC, ABC и так далее.

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

Кстати, по моему мнению, это самая большая и самая компетентная в процессах группировка (но ограниченно компетентная).

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

Правда был вступительный доклад Владимира Репина. Но, во-первых, у него на все выступление было минут тридцать. А во-вторых, он ограничил свое выступление темой сквозных бизнес-процессов.

Кстати, у меня с ним получился незаконченный диалог. Он несколько раз сказал, что нужно использовать только стабильные и устойчивые процессы. А когда я его спросил, нет ли здесь противоречия с его предыдущим утверждением (о важности процессов для адаптации деятельности компании к быстрым изменениям среды), ответил, что вопрос надуманный.

Устойчивость – это динамическая характеристика систем управления, когда мы не можем одновременно обеспечить предсказуемую и быструю реакцию на управляющее воздействие. И если бы мы говорили о процессах управления, то позиция Владимира Репина была бы вполне понятной (хотя и в этом случае можно не отказываться от процесса управления совсем, а настраивать его параметры).

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

Что касается систем управления бизнес-процессами (BPMS), то они стали главной темой прошедшей конференции. Думаю, это было ее слабым местом, так как доклады в основном касались проблем разработки и внедрения BPMS и некоторых смежных технологий, типа SOA и ESB. Ну и, естественно, было много рекламы.

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

Лично на меня произвел рассказ Романа Ткачева из BI Telecom о внедрении BPMS Lombardi и ESB Progress в компании Росно. Для системы «Обработка страховых убытков» было создано 380 сервисов (к каждой activity прикреплялся свой сервис,), большинство из которых – сложные (построены из других сервисов). Правда неоднозначное впечатление произвело то, что один из процессов состоял из 230 activities (видов деятельности).

Кстати, я спрашивал Виктора Солопова из BI Telecom, можно ли в Lombardi менять схему процесса во время реализации экземпляра процесса (например, для процесса долгосрочного кредитования). Ответил, что можно перескочить на другую схему в любой точке экземпляра, привязанной к событию (возможно, такое могут большинство BPMS?).

Один из докладчиков (по моему, Алексей Добровольский из фирмы Крок) в основном говорил о трудностях и к концу основательно всех запугал. Стало ясно, что внедрение BPMS – дело избранных и без специалистов (КРОК?) обречено на провал.

Запомнил еще выступление Федора Краснова из компании Акадо. Возможно, многие впервые узнали о том, как BPMS конкурирует за ресурсы с другими системами типа ERP и CRM, в которых есть движок workflow. И как трудно убедить в различии систем тех, кто дает деньги.

Немного расслабились, когда Юрий Зеленков из НПО «Сатурн» рассказывал об этапах большого пути к процессам вообще и к BPMS в частности. В общем конечно интересно, так как это реальный опыт реального руководителя. Хотя больше произвел впечатление артистизм докладчика.

Кстати, в Сатурне ставили Unify. К Unify имели отношение еще два докладчика. Юлия Вагнер красочно описала, какие требовательные эти клиенты, не хотят стандартный интерфейс от Unify и приходится тратить уйму времени на программирование. А маэстро Белайчук, проскочив по своим слайдам со скоростью звука, был доступен в кулуарах.

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

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

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

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

Если говорить об общем впечатлении, то было достаточно интересно. Особенно в конце, когда ведущий предложил обсудить некоторые высказывания из статьи Марка Макгрегора (есть на bpms.ru). Типа, настоящий внедренец BPM – это тот, который ориентирован на клиента и заботится о качестве. Судя по обсуждению, эта истина для многих оказалась неожиданной.

В конце концов дискуссия перешла в область практического опыта работы и все согласились, что заказчика нужно вести в ресторан. Ведущий Павел Иванов пытался сопротивляться, но идеи иссякли и конференция закончилась.

Валерий Лопатин

>> Комментарии (всего 5)

Какими будут BPM-системы следующего поколения?

В наших публикациях однажды уже проскальзывало мнение о том, что нынешние BPM-системы – еще не венец эволюции: «Семь заблуждений из области исполнения бизнес-процессов». Недавно эту тему развил Брюс Силвер в своей колонке на сайте BPMInstitute.org: «BPMS Watch: The Next Innovation in BPMS».

Он начинает со сравнения BPMS с инструментарием класса BPA (Business Process Analysis) и EA (Enterprise Architecture), от простых плагинов к Visio до навороченного ARIS. У BPMS по сравнению с ними есть всего одно преимущество: способность исполнять нарисованные схемы, т.е. становиться костяком информационной системы. Но преимущество это решающее, поскольку только таким путем удается выйти из стандартной ситуации, при которой аналитики и ИТ-специалисты существуют в параллельных, не соприкасающихся друг с другом мирах, и избавиться от вечного проклятия – автоматизации не до конца понятых или явно неоптимальных бизнес-процессов.

Вместе с тем, выигрывая в этом, BPMS проигрывает в нескольких других отношениях. Во-первых, то, что называется процессом в BPMS, с точки зрения методологии процессного управления не более чем фрагмент сквозного кросс-функционального процесса. Каждый, кто пытался на практике реализовать в BPMS сквозной процесс типа «от заказа до оплаты», знает, что технически он моделируется несколькими взаимодействующими друг с другом процессами. Но BPMS плохо умеют работать на уровне выше отдельного процесса: на каждой диаграмме вы моделируете только один процесс и связи его с другими процессами, а возможности показать совокупность процессов, составляющих единое логическое целое у вас нет. Если сравнить это, например, со средствами разработки баз данных, то там у вас обычно есть общий репозитарий таблиц (с полями, индексами и прочим), из которых вы можете складывать разные диаграммы. Аналогичным образом, хочется иметь возможность комбинировать сквозные процессы из фрагментов, но EA инструменты такую возможность предоставляют, а BPM-системы – пока что нет.

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

Наконец, аналогичная картина еще с целым рядом артефактов: бизнес-правилами, KPI, организационной структурой, сервисами. EA позволяет достаточно системно их описывать, но это не более чем описание: идеализированное представление аналитиков, физически оторванное от реализации, которой заведует другое ведомство – ИТ.

BPM-системы следующего поколения должны распространиться на все перечисленные области, применив к ним свое «ноу-хау» – стирание различия между представлениями аналитиков и ИТ-специалистов по формуле «единая модель, разные представления».

В конце заметки Брюс задается вопросом: а не идет при этом фактически речь о переносе существующей функциональности EA и BPA систем в BPMS? И честно признает: да, именно об этом. Потому что ожидать движения с обратной стороны, со стороны EA и BPA, по-видимому не приходится. Брюс советует посмотреть как изменятся BPM-системы от ведущих вендоров через год. Человек он информированный – будем надеяться, прогноз сбудется.

=АБ

>> Комментарии (всего 0)

Анимированный справочник по BPMN

BPMN постепенно завоевывывет все более широкое признание, становясь де-факто основным стандартом в области моделирования бизнес-процесов. Его роль можно сравнить с ролью SQL в области СУБД: с одной стороны, для практической работы необходимо изучить особенности диалекта конкретной СУБД, но с другой, профессионал обязан знать стандарт. Так же и тут: ни один вендор BPMS сегодня не поддерживает BPMN один-в-один, но именно поэтому надо знать стандарт, чтобы грамотно выбрать BPMS и грамотно ею пользоваться. В то же время и сам стандарт, и документ его описывающий критикуют за неоднозначность и недостаточно четкое изложение. Поэтому оказываются востребованы тренинги и учебные пособия по BPMN, которые акцентируют внимание на реализации средствами BPMN типовых процессных паттернов. Мы уже давали ссылки на тренинги; еще один полезный (и бесплатный) ресурс такого рода - diveintobpm.org. Его «изюминка» - анимированные слайды, наглядно демонстрирующие передачу управления между шагами бизнес-процесов. К сожалению, не хватает столь же наглядных иллюстраций к процессной хореографии - передаче сообщений и координации между асинхронно исполняющимися бизнес-процессами.

=АБ

>> Комментарии (всего 0)

Визионеры SOA: Michael Stamback, Oracle

В разделе подкастов на ebizQ появилось интересное интервью Michael Stamback, в котором он делится своими взглядами на SOA вообще и на SOA Governance в частности. Интервью доступно в виде аудиозаписи и расшифрованного текста. Вводные фразы и рекламу Oracle мы опустили, а некоторые интересные фрагменты предлагаем вашему вниманию в переводе на русский.

Вначале SOA Governance в основном фокусировалось на UDDI Registry и на том, как с их помощью можно делать то, что называется «управлением во время разработки» (Design-Time Governance). От него откололось то, что называется управлением во время исполнения (Runtime Governance), и есть вендоры, которые до сих пор об этом говорят.

Но потом направление, в котором стали развиваться registry, привело к необходимости repository, а затем захотелось иметь возможность абстрагировать бизнес-политики в нечто, что бы могло исполняться в среде исполнения. Эволюция всего этого пространства была очень интересной.

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

Сегодня область технологии SOA Governance разбивается на четыре разные категории: управление активами, управление потреблением, управление политиками, и еще операционные или времени исполнения мониторинг и управление. И с моей точки зрения, один из важнейших, если не самый важный аспект, необходимый для программы SOA Governance – это управление активами.

Потому что одна из выгод SOA – это гибкость (agility), дающая бизнесу приложения, быстро собираемые из готовых к употреблению сервисов. Но вы не достигнете повторного использования, если вы не видите что у вас есть готового к использованию. И, продолжая эту мысль, вы не можете управлять тем, чего не видите.

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

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

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

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

У вас также может быть набор SLA которые по существу задают гарантированную производительность или пропускную способность, которую вы обеспечиваете данному потребителю данного сервиса. И это последний кусочек SOA – мониторинг и управление.

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

В случае Oracle, мы предлагаем решение SOA Governance, удовлетворяющее всем этим различным критериями. В области управления активами у нас есть Oracle Enterprise Repository и Oracle Service Registry. Они пришли вместе с приобретением BEA, а до BEA они были известны как Flashline.

В области управления политиками и управление потребителями, связанный с потреблением процесс реализован в рамках workflow, встроенного в наш Oracle Enterprise Repository. А управление политиками обеспечивается через продукт Oracle Web Services Manager. И в области мониторинга и управления SOA мы предоставляем пакет SOA management, обеспечивающий видимость показателей времени исполнения.

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

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

=АБ

>> Комментарии (всего 0)

Путеводитель для путешественников по стране BPM

На сайте ebizQ в разделе Archived Webinar советую обратить внимание на тему «Getting Started with BPM».

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

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

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

Несколько слайдов из презентации:

Новая версия модели стадий зрелости BPM от Gartner:

  1. Осознание операционной неэффективности
    • измерение шагов процесса
    • моделирование и анализ бизнес-процесов
  2. Осознание процессов
    • определение метрик эффективности процессов
    • определение владельцев процессов
  3. Внутрипроцессная автоматизация и управление
    • создание управляющей инфраструктуры
    • сопоставление альтернатив при помощи имитационного моделирования
    • интегрированный учет от шагов процесса
  4. Межпроцессная автоматизация и управление
    • выстраивание процессов в соответствии с маркетинговой стратегией
    • налаживание автоматизации процессов сквозь организацию
  5. Управление оценкой компании
    • увязывание оценки бизнеса с исполнением процессов
    • процессы, ориентированные на результат
  6. Подвижная бизнес-структура
    • инновации в бизнесе, продукции и услугах

 

Центр компетенции BPM

  1. Спонсор из числа высшего руководства
  2. Директор по бизнес-процессам
    • руководит центром компетенции
    • устанавливает относящиеся к процессам политики, управление и методологию
    • определяет и доносит до остальных процессную стратегию
  3. Проектный менеджер
    • управляет проектом и обновляет информацию
    • разрешает и эскалирует проблемы
    • координирует усилия
  4. Проектная команда
    • предоставляет экспертизу в управлении изменениями, управлении процессами и других дисциплинах
    • выполняет анализ отправных точек, текущей эффективности и потенциала усовершенствования
    • предоставляет бизнесу рекомендации по оптимальному подходу к усовершенствованию
  5. Аналитик бизнес-процессов
    • определяет необходимые навыки
    • документирует шаги и модели на уровне задачи
  6. Эксперт в предметной области
    • предоставляет бизнес-экспертизу и базовые знания
    • участвует в рабочих сессиях

Спонсор из числа высшего руководства

  • имеет возможность уделять проекту время
  • сильные навыки персональной коммуникации
  • способен принимать решения
  • пользуется уважением во всей организации
  • способен оказывать влияния на всех уровнях организации
  • заинтересован в успехе

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

 

Определитесь с целями:

  • подвижность бизнеса
  • скорость вывода на рынок продукции и услуг
  • соответствие требованиям регулирующих органов
  • удовлетворенность клиентов
  • эффективность
  • снижение затрат

 

Gartner подчеркивает: критичный фактор успеха – не ограничивайтесь только моделированием процессов. Странный призыв. Как вообще можно называть чистое моделирование BPM? Но видимо, жизнь заставляет повторять раз за разом.

Тщательно выбирайте первый проект:

  • высокая отдача/низкий риск
  • достижимые цели
  • видимый результат
  • соответствующий стратегии
  • очерченные границы

=АБ 

>> Комментарии (всего 0)

Конференция по BPM, кулуарные подробности

В преддверии Третьей ежегодной конференции по управлению бизнес-процессами, которая пройдет в Москве 24 сентября, редакция BPMS.ru задала несколько вопросов главе оргкомитета конференции, директору Агентства корпоративных коммуникаций OSP-Con Павлу Иванову.

Анатолий Белайчук, BPMS.ru (АБ): Павел, в этом году конференция пройдет в новом месте, в отеле Рэдиссон-Славянская возле Киевского вокзала. С чем связана смена площадки и как она отразится на формате конференции?

Павел Иванов, OSP-Con (ПИ): Нет, формат останется традиционным, просто это – удобная, более просторная площадка. У нас будет большая зона для стендов участников и много места для кулуарного общения.

АБ:      Вы ожидаете большего, чем в прошлые годы, числа участников?

ПИ:     За два месяца до мероприятия, особенно летом, рано говорить о числе посетителей, но во всяком случае, если смотреть по «игрокам» рынка, то к BPM-вендорам, участвовавшим в прошлых конференциях, в этом году должны добавиться несколько новых. Кроме того, ряд компаний представят свои реальные кейсы.

АБ:      А что с тематикой, будет ли в этом году сделан акцент на какое-то направление внутри общей темы BPM?

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

АБ:      Идеальная конференция – та, в которой соблюден баланс между выступлениями аналитиков, вендоров и практиков. Аналитики могут сравнить свои построения с жизненными реалиями, а вендоры – свои продукты с взглядами аналитиков и практиков. Вы приближаетесь к этому идеалу?

ПИ:     Да, я бы сказал, что мы начинаем приближаться к формату других наших конференций, таких как Business Intelligence, ITSM. Скажем, на последней ITSM-конференции в мае этого года, после пленарной части программа была разбита на два тематических потока. Мы видим, что тематика наших мероприятий, посвященных управлению бизнес-процессами, BPM становится все более зрелой. В будущем мы, видимо, и эту конференцию переведем на такой регламент.

АБ:      В порядке критики: не слишком ли вы сузили название – «Управление бизнес-процессами на предприятии»? Если верить западным публикациям, то самый большой спрос на BPM «там» – в вертикалях Banking, Insurance, Healthcare, Federal Government. Получается, вы не охватываете самых главных потенциальных потребителей: банкиры и страховщики ведь не называют свои организации «предприятиями», не говоря уже о бюджетных организациях и органах власти. У последних, кстати, термин «бизнес-процесс» вообще не приветствуется, там это называется «административный регламент».

ПИ:     Слова «на предприятии» – прямой перевод английского enterprise, который охватывает весь корпоративный сектор, а не только производство. На российском ИТ-рынке под enterprise понимают и госучреждения, хотя это не вполне корректно. Мы, конечно же, всячески приветствуем участие в конференции по BPM представителей кредитных учреждений, страховых компаний, бюджетных организаций, органов власти.

АБ:      Вообще-то, по моему, enterprise business process – синоним термина end-to-end business process, то есть это акцент на «сквозных» бизнес-процессах в противоположность процедурам внутри одной бизнес-функции, которые тоже иногда называют бизнес-процессами.

ПИ:     Согласен, это создает некоторую двусмыслицу. Мы подумаем и возможно в будущем слова «на предприятии» просто выкинем из названия конференции, ничего от этого не убудет.

АБ:      Недостатком прошлой конференции (кстати, в отличие от первой) было то, что ответы на вопросы оказались скомканными. Докладчики выбивались из регламента, так что физически не было возможности задать вопрос. А выступления без вопросов – это, извините, шоу, а не конференция. Общее обсуждение или «круглый стол» в конце тоже не было запланировано. Что Вы думаете по этому поводу?

ПИ:     Мы заранее пишем всем докладчикам, что выделенное им время подразумевает 3-5 минут для ответов на вопросы, но это не очень помогает. Пробовали с упреждением сигнализировать докладчику, что его время истекает, но докладчики от спонсоров очень ревностно за этим следят, так что этот трюк тоже не проходит. Короче говоря, готового решения у меня нет, кроме как годами «воспитывать» докладчиков, что не очень продуктивно. В принципе, вопрос докладчику можно задать в кулуарах, но я согласен, это должно быть дополнением, а не заменой диалогу в зале. Что же до дискуссии, то это обязательный компонент наших мероприятий, и она присутствовала в программе. Но проблемы с регламентом заставили по ходу дела от дискуссии отказаться. Спасибо за критику, постараемся ее учесть.

АБ:      Ну и напоследок, можете сформулировать для наших читателей три причины, по которым им нужно посетить конференцию?

ПИ:     Конечно. Первое: от процессного управления никуда не деться. Конкуренция во всех отраслях нарастает, и более убедительного рецепта, чем выстраивание сквозных бизнес-процессов «от клиента», на сегодня просто нет. Поэтому надо двигаться в этом направлении. Надо учиться, и лучше это делать на чужих ошибках. Мы даем возможность прийти и познакомиться с опытом других. Можно и нужно учиться по литературе, но конференция – это возможность не только прочитать «мертвый» текст, но и задать вопрос, в кулуарах побеседовать с вендором или партнером. Второе. На конференции представлены все ключевые игроки, присутствующие на нашем рынке,– это экономит кучу времени. За один день вы можете составить представление обо всех имеющихся на рынке предложениях, что в других условиях займет недели. И третье. Данная тематика с такой полнотой и охватом в России не представлена больше нигде. Поэтому если вы всерьез интересуетесь процессным управлением и BPM, то вам не просто нужно – вы обязаны посетить нашу конференцию.

АБ:      Павел, спасибо за интересные ответы. Желаю Вам, чтобы каждый год конференция по BPM проходила успешнее предыдущей.

ПИ:     Анатолий, спасибо за вопросы, за заинтересованную критику и за пожелания. Надеюсь встретить читателей портала BPMS.ru на конференции 24 сентября. Регистрируйтесь на сайте osp.ru, приходите, не пожалеете.

>> Комментарии (всего 0)

Стандарты бизнес-процессов - это реально?

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

Так что же является стандартом в BPM? Не давая однозначного ответа на этот вопрос, Джим Синур в своей статье «озвучил» свой взгляд на стандарты.

Итак, что же такое стандарты в понимании Синура:

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

XPDL – самый практичный транспортный механизм из доступных сегодня, и в числе прочих он легко может поддерживать модели BPMN. Я бы сделал ставку на XPDL в качестве стандарта обмена моделями процессов, но я пристально слежу за BPDM, чтобы понять, будет ли он востребован и достаточно ли он практичен. Комбинация BPMN и XPDL конечно обнадеживает, но надо, чтобы два конкурирующих производителя стандартов работали вместе (OMG в случае BPMN и WfMC в случае XPDL). Множество светил, таких как Роберт Шапиро, Брюс Силвер и Кейт Свенсон, стремятся сделать это реальностью. Надеюсь, это движение набирает обороты.

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

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

  =WJ

>> Комментарии (всего 8)

Oracle решает судьбу продуктов BEA
«Войны не будет, но будет такая борьба за мир, что камня на камне не останется»

Президент Oracle Чарльз Филлипс (Charles Phillips) и Старший вице-президент Томас Куриан (Thomas Kurian) в онлайновом выступлении 1 июля объявили о стратегии дальнейшего развития продуктов BEA и Oracle. Продуктовая линейка BEA включается в состав Oracle Fusion Middleware. Все продукты BEA разделены на три категории:

  • Стратегические продукты
    • Продукты BEA, которые будут преобразованы в Oracle Fusion Middleware с небольшими изменениями
    • Продукты, не имеющие аналога у Oracle, в большинстве случаев сохраняются
    • Комплиментарные продукты Oracle и BEA объединяются в единый продукт в течение 12-18 месяцев
  • Развивающиеся и сближающиеся продукты
    • Продукты BEA, которые будут переделаны для интеграции с Oracle Fusion Middleware
    • Постепенная интеграция с Oracle Fusion Middleware технологиями в целях расширения возможностей продолжения разработки и поддержки, по крайней мере, в течение 9 лет
  • Поддерживаемые продукты
    • Продукты BEA, которые находились в этом статусе еще до приобретения Oracle
    • Продолжение поддержки в течение 5 лет

В чем принципиальная разница между стратегической разработкой и развитием и сближением – не очень понятно. В своем обзоре Сэнди Кемслей (Sandy Kemsley) также недоумевает по этому поводу:

Возникает вопрос по поводу частичного перекрывания между категорией «стратегические» , которая может включать в себя сведение в одну точку продуктов Oracle и  BEA, и категорией «развивающиеся и сближающиеся», которая включает продукты, которые будут переделаны в другой продукт: когда продукт относится к «стратегическому», а а когда к «развивающемуся и сближающемуся»? Или это всего лишь уловка, и они представляют все таким образом, чтобы не отпугнуть заказчиков BEA, которые вложили огромные инвестиции в продукты BEA, которые будут преобразованы в продукты Oracle?

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

Вот что ждет SOA:

 

  •  Стратегические
    • Oracle Data Integrator  для интеграции и объединения ETL (extraction, transformation, loading -  извлечение, преобразование и загрузка)
    • Oracle Service Bus объединит AquaLogic Service Bus и Oracle Enterprise Service Bus
    • Oracle BPEL Process Manager для оркестровки сервисов и инфраструктуры композитных приложений
    • Oracle Complex Event Processor для обработки событий, интегрированный с WebLogic Event Server
    • Oracle Business Activity Monitoring для отслеживания бизнес-событий и KPI
  • Развивающиеся и сближающиеся
    • BEA WebLogic-Integration будет развиваться дальше на основе технологии Oracle BPEL Process Manager
  • Поддерживаемые
    • BEA Cyclone  и BEA RFID Server заканчивают свое существование

Негусто, надо сказать. Все, что продолжит жить, будет заменено Oracle, а все остальное - end-of-life.

Зато в BPM признается явное преимущество BEA в human-oriented BPM. Что останется:

 

  • Стратегические
    • Oracle BPA Designer (лицензированный ARIS) для моделирования и имитационного воспроизведения процессов
    • BEA AquaLogic-BPM Designer для итеративного моделирования процессов
    • Oracle BPM – объединение BEA AquaLogic BPM и Oracle BPEL Process Manager в одном рантайм-движке
    • Oracle Document Capture & Imaging – документооборот с интеграцией с ERP
    • Oracle Business Rules – движок бизнес-правил
    • Oracle Business Activity Monitoring для отслеживания бизнес-событий и KPI
    • Oracle WebCenter – портал для взаимодействия с визуальными компонентами процесса

В этом направлении все продукты признаются Oracle стратегическими. Однако вот мнение Брюса Силвера (Bruce Silver):

Что касается BPM – Oracle  пытается поделить ребенка пополам. Существующий BPA Suite (OEM ARIS) позиционируется как «стратегический» инструмент моделирования с высоким приоритетом, а BEA AquaLogic BPM, известный ранее как Fuego, кажется обрел свою крышу как «agile BPM» инструментарий, пригодный для использования экспертами, не принадлежащими к сфере ИТ. Я не уверен, что BEA когда-либо позиционировал AquaLogic именно так, но позиционирование ALBPM  как гибкого (по сравнению с BPA Suite + SOA Suite) – это неслыханный уровень откровений… возможно даже чрезмерный, так что посмотрим, как долго это продлится. Не уверен, что они понимают, как это сделать, но план кажется состоит в том, чтобы поддержать ALBPM среду моделирования – плохая новость для BPA Suite? – и перенести среду исполнения ALBPM на единый движок, который сможет выполнять и BPEL, и BPMN 2.0 с общим контролем и управлением. Oracle заявил, что ALBPM будет интегрирован с BPEL метамоделью для  «round trip»  и «процессная документация» будет доступна через BPA Suite. Насколько это будет мешать ALBPM и насколько усилит BPEL – пока неизвестно.

Говоря о портале, Куриан подробно объяснил, каким образом WebLogic Portal  и AquaLogic UI вольются в Oracle.

 

  • Стратегические
    • Oracle Universal Content Management – репозиторий, безопасность, публикация, отображение, регистрация фактов и архивирование
    • Oracle WebCenter Framework – для разработки портала и Enterprise 2.0 сервисов
    • Oracle WebCenter Spaces & Suite -объединенные среда самообслуживания портала и общие компьютерные службы
    • BEA Ensemble & Pathways – легковесный, основанный на REST –сервисах портал и аналитика взаимодействий
  • Развивающиеся и сближающиеся
    • BEA WebLogic Portal будет интегрирован в WebCenter Framework
    • BEA AquaLogic User Interaction (AL-UI) будет интегрирован в WebCenter Spaces & Suite
  • Поддерживаемые
    • BEA Commerce Services и Collabra

 

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

 =WJ

>> Комментарии (всего 1)

Тренинги по BPM
BPMInstitute.org BPM101

BPM Institute (www.bpminstitute.org) предлагает широкий спектр тренингов по BPM и SOA. Для российских специалистов особый интерес может представлять появившийся недавно онлайновый вариант базового тренинга «BPM101». Курс состоит из 6 модулей приблизительно по одному академическому часу:

  1. Введение в BPM
  2. Концепции и принципы BPM
  3. Анализ, проектирование и управление процессами
  4. Инструментарий и технологии
  5. BPM в масштабах предприятия
  6. Отраслевые примеры и кейсы

Модуль 6 пока не вышел, зато обещан дополнительный модуль:

  1. Финансовое обоснование для BPM

К достоинствам курса можно отнести широкий охват: BPM преподносится не как магический рецепт, а как органичный результат эволюции управленческой мысли и развития информационных технологий. Опыт предыдущей волны управления бизнес-процессами под флагом реинжиниринга не отвергается, а анализируется и утилизируется, например, для выработки стратегии внедрения процессного управления в масштабе предприятия через т.н. «управление портфелем бизнес-процессов» (Process Portfolio Management, модуль 5). Также рассматриваются организационные составляющие этой стратегии, в частности, роль владельцев процессов, центра компетенции по BPM и т.д. Роль BPMS анализируется с позиции не ИТ, а бизнеса: как полезного, а в некоторых случаях – необходимого инструмента процессного управления.

Курс может быть рекомендован в первую очередь менеджерам и бизнес-аналитикам. Цена: $595.

Bruce Silver BPMN Training

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

Не секрет однако, что BPMN – достаточно эклектичный стандарт (или, по деликатному выражению авторов стандарта, «methodology-neutral»). Поэтому каждый, кто с ним знакомится, сталкивается с тем, что один и тот же процесс в нем можно смоделировать совершенно разными конструкциями. Число этих конструкций даже в версии 1.0 стандарта достаточно велико, а в версии 1.1 оно еще увеличилось. Плюс к этому, многие из этих конструкций не поддерживаются существующими BPM-системами. Поэтому осваивать BPMN через изучение стандарта – не самая лучшая идея.

Может быть основная ценность курса Брюса Силвера – это то, что он показывает как использовать BPMN на практике. От простого к сложному, с достаточно жизненными примерами и иллюстрациями. Брюс – один из наиболее авторитетных экспертов в области BPM, к мнению которого прислушиваются и аналитики, и потенциальные заказчики, и вендоры. Он принимает непосредственное участие в выработке стандартов в области BPM, поэтому его рекомендациям по практическому их использованию безусловно можно доверять.

Полный вариант курса доступен на сайте www.bpmessentials.com. По цене $695 вы получаете 60-дневный доступ к материалам курса и временную лицензию на «рисовалку» BPMN для Microsoft Visio на тот же срок, а за $1190 – доступ к материалам курса на 12 месяцев и перманентную лицензию.

Сокращенный вариант этого же тренинга SAP предоставляет бесплатно при условии регистрации на сайте SAP Community Network: «Process Modeling With BPMN: Six-Part eLearning Series». Печатный вариант «Process Modeling With Business Process Modeling Notation (BPMN) - Article Series» в основном повторяет онлайновый курс, но плюс к этому содержит дополнительный «продвинутый» материал – описание средствами BPMN взаимодействия нескольких процессов.

=АБ

>> Комментарии (всего 12)

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