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


 
Обзоры, выпуск 4, 2006 г.

Литература:

«Слияния и поглощения 2006 года»

IBM купил, BEA купил, Oracle купил, кто следующий?

Cлишком много вендоров, и предсказывает сокращение их числа, в том числе за счет слияний и поглощений. Что ж, игра началась. В 2006 году среди игроков Workflow-BPM и SOA происходило заметное встречное движение. Первые пытались усилить свои позиции за счет SOA, вторые — за счет так называемого «human-facing BPM», иначе говоря, Workflow.

1. BEA Systems и Fuego

Первой ласточкой стала BEA Systems, купившая за $87.5 миллионов компанию Fuego, одного из ведущих поставщиков ПО для управления бизнес-процессами (март 2006).

Коментарий исполнительного директора компании BEA Альфреда Чуанга:

Добавление Fuego к портфелю AquaLogic делает нас единственной на сегодняшний день компанией, предлагающей унифицированную SOA-платформу для интеграции бизнес-процессов, приложений и уже существующих систем.

Комментируя это заявление, Сэнди Кемсли замечает:

Вероятно, не все конкуренты BEA и Fuego согласятся с определением «единственный», и напомнят о приобретении Staffware TIBCO несколько лет назад. Fuego послужит базисом для создания платформы BEA AquaLogic Business Service Integration и даст BEA намного больше поводов обращаться к руководителям бизнеса, вместо того, чтобы беседовать «за жизнь» с парнями из ИТ.

Другой, не менее известный аналитик, Терри Шуртер по тому же поводу:

Движение BEA в сторону BPM было ожидаемым, и выбор в пользу приобретения Fuego определенно не стал сюрпризом. Fuego обладает очень сильной репутацией на рынке pure-play BPM, компания почти (или совсем) не обременена балластом, а ее технология хорошо стыкуется с существующим портфелем BEA. Этого достаточно, чтобы сказать, что BEA, TIBCO и webMethods теперь возглавят новое большое наступление на рынок средств управления бизнес-процессами, расширив возможности своих пакетов и предлагая унифицированные приложения для BPM (business process management), SOA (service oriented architecture), BR (business rules), BAM (business activity monitoring), CEP (complex event processing), и т.д.

А господин Винайяк имеет другое мнение на это счет:

Почему же BEA все-таки купил Fuego, если у него имеется собственный BPM-движок? К тому же, существует ли путь миграции для пользователей текущего движка? Причины, по которым BEA купил Fuego, кроются в том, что их собственный движок, по-видимому, не может предложить достаточных возможностей в плане Workflow и кроме того, он оказался слабоват в описании и управлении — двух существенных компонентах жизненного цикла процессов.

2. IBM и FileNet

Круглую сумму потратил IBM на приобретение другого вендора, не менее успешного но из разряда ECM (Enterprise Content Management) — компанию FileNet (октябрь 2006). Выложив за покупку $1.6 миллиардов, IBM намеревается интегрировать FileNet-овский ECM с BPM и SOA технологиями.

Сами покупатели очень сдержаны в оценках, их коментарии сводятся примерно к следующему:

IBM интегрирует свои BPM и SOA технологии с FileNet платформой для того, чтобы предоставить заказчикам доступ к контенту везде, где бы они не находились, и использовать его в контексте бизнес-процессов.

Похоже, что сделка не очень удивила ведущих мировых аналитиков, т.к. их комментарии больше похожи на констатацию факта. Вот что пишет об этом Сэнди Кемсли:

Меня не удивила покупка FileNet, т.к. разговоры об этом ходили еще тогда, когда я была в FileNet, и даже раньше; я была удивлена лишь тем, что это IBM, я всегда представляла себе, что это будет Oracle ... однако я не уверена, что FileNet content management имеет большое будущее внутри IBM.

Джим Мерфи, руководитель исследовательских работ AMR Research Inc. прокомментировал это событие так:

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

Мнение Терри Шуртера:

Покупка конечно же имеет смысл, и это демонстрирует растущую важность BPM на всех уровнях производства ПО. IBM подхватывает игру на этом рынке. Приобретение FileNet может стать рычагом для того, чтобы занять очень выгодные позиции в обеих нишах рынка BPM (технологическая архитектура и вопросы бизнеса).

3. EMC и ProActivity

EMC, уже присоединившая к себе в 2003 году Documentum, сделала следующий шаг к укреплению своих позиций на рынке BPM. Сделка по приобретению ProActivity Software Solutions Ltd (июнь 2006) менее масштабна, чем у IBM и BEA, но результаты ее вызывают оптимизм у обеих сторон. Мнения участников сделки:

Дейв ДеВолт (Dave DeWalt), президент EMC Software Group:

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

Эви Фогиль (Avi Fogel), председатель совета директоров и исполнительный директор ProActivity:

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

4. Oracle и IDS Scheer

Корпорация Oracle включила в свою продуктовую линейку разработанную компанией IDS Scheer платформу ARIS Platform (август 2006).

Аналитики Gartner оценивают это событие следующим образом:

Это партнерство может принести выгоду как заказчикам, так и обоим вендорам. Выгода IDS Scheer в том, что заказчики Oracle, которые используют отличные от ARIS средства моделирования, пересматривают свой текущий инструментарий и раздумывают о том, чтобы переключиться. Выгода Oracle в том, что те, кто имеют инструменты моделирования, имеют возможность быстрее и более успешно реализовать свои прикладные решения.

Брюс Сильвер не постеснялся назвать вещи своими именами, и его прогноз на будущее не столь безоблачен, как у его коллег:

До сегодняшнего заявления Oracle, насколько я знаю, не предлагал BPM в своей продуктовой линейке. Несомненно, у них есть SOA Suite, который включает BPEL Process Manager и BPEL Designer — блестящие продукты — но компания никогда не имела смелости заявить: «Мы понимаем, что такое BPM, и у нас есть BPM решение». Несколько месяцев назад я пытался убедить шефов BPEL в Oracle официально объявить себя участниками BPMS баталий, но они не чувствовали себя готовыми или у них были проблемы поважнее с SOA. Отсутствующей частью было аналитическое моделирование. Теперь оно есть. И, похоже, что Oracle уже втянут в эту борьбу.

Я все еще сомневаюсь, что Oracle выдвинет BPMS на рынок в манере, скажем, IBM или BEA. Я думаю, что Oracle пока видит BPM (а также и SOA) только как позднюю эволюцию борьбы промышленных приложений, которая в основном является гонкой двух фаворитов. Программные средства должны поддерживать пакетные приложения, делая их более гибкими и лучше интегрируемыми с внешним миром и т.д. В конечном счете эта сделка может откинуть Oracle’s Fusion Applications гораздо дальше от позиции в Магическом квадранте, на которой сейчас находится Oracle.

5. TA Associates и Global 360

Компания Global 360, поставщик полноценного Business Process Management Suite (BPMS), была куплена крупной инвестиционной компанией TA Associates за $200 миллионов (апрель 2006). Global 360 специализируется на таких технологиях, как content management, process management, goal management, process modeling, прогнозирование, моделирование, анализ, составление отчетов и оптимизация. Ее клиентами являются семь из десяти крупнейших страховых компаний, шестнадцать из двадцати крупнейших банков и множество американских федеральных агентств.

Похоже, что сами они вполне довольны, что нашли инвесторов, поскольку это позволит им активизироваться на рынке, на котором сейчас появилось так много конкурентов, что легко можно остаться за бортом. Комментарий Михаила Кросно, исполнительного директора Global 360:

Мы довольны нашими новыми инвесторами как акционерами. Мы чрезвычайно стимулированы этим стратегическим союзом, потому что у нас появляются средства для роста и приобретения необходимых промышленных знаний, поскольку мы поднимаем Global 360 в десятку лидеров рынка.

Эта сделка является обычной инвестицией и не изменяет структуру и состав продуктовой линейки, поэтому факт для потребителя не представляет большого интереса. Тем более, что в России Global 360 не пользуется большой популярностью.

Немного истории

В предшествующие годы на рынке BPM тоже произошло несколько значимых событий, о которых уместно вспомнить:

  • В 2005 году Metastorm и CommerceQuest объявили об объединении своих усилий для создания под брендом Metastorm «лидера на рынке Pure-Play BPM». По сути дела, это чистейшей воды поглощение, при котором от CommerceQuest остаются лишь воспоминания.

  • Еще одно событие 2005 года — объединение Seagull Software и Oak Grove Systems. Seagull Software усилила таким образом свои позиции на рынке BPM, добавив к имеющимся SOA-технологиям инструментарий для моделирования и исполнения процессов. Это слияние — яркий пример создания качественно более ценного с точки зрения потребителя продукта — полновесной BPM-системы.

  • В 2004 году компания TIBCO приобрела Staffware, образовав TIBCO BPM Group. По этому поводу стоит сказать, что Staffware был одним из первых вендоров, специализоровавшихся на pure-play BPM. Цена покупки составила $217 миллионов.

Дополнение (добавлено 09.02.2007)

  • В августе 2005 года произошло еще одно крупное слияние. Компания Sun Microsystems присоединила к себе SeeBeyond Technology Corporation, в результате чего, по словам президента и исполнительного директора Sun Microsystems Джонатана Шварца: «SeeBeyond технологии существенно повысили ценность нашей Java Enterprise System платформы, и предоставили целое решение с технологиями будущего поколения и сервисами для интеграции унаследованных приложений внутри новых композитных приложений. »

— WJ 29.12.2006

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

«BPM Maturity Model Identifies Six Phases for Successful BPM Adoption». Michael James Melenovsky, Jim Sinur

Модель зрелости BPM определяет шесть ступеней реализации преимуществ BPM организациями.

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

Стадия 0: Осознание неэффективности операций (Acnowledge Operations Inefficiency)

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

Стадия 1: Заинтересованность в процессах (Process Aware)

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

Стадия 2: Локальное процессное управление и автоматизация (Intraprocess Automation and Control)

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

Стадия 3: Управление и автоматизация межпроцессного взаимодействия (Interprocess Automation and Control)

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

Стадия 4: Управление цепочкой добавленной стоимости (Enterprise Valuation Control)

Накопленная компетенция позволяет настраивать исполнение процессов в цепи бизнес-партнеров под стратегические цели компании.

Стадия 5: Подвижная бизнес-структура (Agile Business Structure)

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

Основная масса компаний в настоящее время находится на нижних стадиях зрелости, и даже к 2008 году это распределение изменится незначительно:  

Стадия 0

Стадия 1

Стадия 2

Стадия 3

Стадия 4

Стадия 5

Доля на конец 2006 г. (%)

62

16

2

0

0

0

Доля на конец 2008 г. (%)

55

33

8

2

0

0

 В дополнение к шести стадиям, модель зрелости рассматривает шесть организационных факторов, которые должны сбалансированно развиваться по мере перехода от стадии к стадии:

Информационные технологии (Information Technology)

Программно-аппаратное обеспечение, обеспечивающее и поддерживающее процессное управление.

Методики (Methods)

Подходы и приемы, позволяющие успешно реализовывать процессное управление.

Руководство (Governance)

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

Люди (People)

Группы и индивидуумы, непрерывно развивающие и применяющие на практике навыки процессного управления.

Культура и лидерство (Culture and Leadership)

Общие ценности и воззрения, формирующие правильное отношение к процессам.

Стратегическая линия (Strategic Alignment)

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

В основой части отчета для каждой из шести стадий зрелости детально рассматриваются перечисленные выше факторы, а также:

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

Полный текст статьи: «BPM Maturity Model Identifies Six Phases for Successful BPM Adoption». Michael James Melenovsky, Jim Sinur, Gartner, Inc.

— WJ 05.12.2006

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

«A Short History of BPM». Sandy Kemsley

Краткий экскурс в историю BPM

«BPM — это никакая не новость, он был известен давным-давно, только назывался по-другому». Такое мнение можно слышать довольно часто. Волей-неволей приходится задумываться и искать ответы на вопросы: если BPM появился давно, то почему раньше он не был столь популярен? Сэнди Кемсли оглядывается назад, в ранние 80-е...

Сначала был «workflow». Термин этот впервые применил FileNet, несмотря на то, что они быстро поделили это место на рынке с IBM и другими игроками. Первые workflow-системы были сфокусированы на маршрутизации движения документов. Но продвижение на рынке шло слишком медленно по сравнению с более функциональными и гибкими продуктами.

Параллельно с workflow, но независимо от него, появилось понятие system-to-system интеграции и Enterprise Application Integration (EAI). Здесь ключевым игроком был IBM с MQ Series, который на долгое время стал стандартом де-факто для многих организаций. Однако, первые EAI-системы не были человеко-ориентированы и предполагали лишь интеграцию на уровне данных. Workflow и EAI в то время жили отдельной жизнью. Workflow предлагался как узковедомственное решение, а EAI — как инфраструктурная компонента.

В конце 90-х workflow и EAI вендоры начали заимствовать друг у друга некоторые элементы функциональности, в результате чего появились EAI с вкраплениями workflow и workflow с вкраплениями EAI.  

Необходимость оптимизировать процессы требовала создания соответствующих инструментов. Организации, использовавшие workflow, вскоре стали испытывать потребность в анализе процессов. Отсюда появился Business Activity Monitoring, или BAM. В то же время вендоры EAI не были озабочены управлением процессами, а обратили свои усилия за пределы организаций, в сторону business-to-business интеграции.

Развиваясь, workflow и EAI стали включать в себя функциональность, полезную обоим, такую как Business Rules Engines (BRE) и инструменты моделирования. Заказчики оказались в замешательстве: где кончается workflow и начинается EAI? Для полноты картины стоит упомянуть концепцию SOA, которая окончательно спутала карты BPM-игроков.

Аналитики Gartner объединили оба направления, назвав все это «BPM suites», но разделив на «pure-play» и «integration-focussed» категории, которые были представлены соответственно на workflow и EAI вендорами.

Что же мы имеем сегодня? Некоторые EAI/ESB вендоры называют свои продукты BPM, хотя они и имеют лишь рудиментарную human-facing функциональность. И наоборот, workflow-вендоры, не имея необходимой инфраструктуры для интеграции, также называют себя BPM. В итоге, каждый вендор дает свое определение возможностей, которыми должна обладать BPM-система. Если какая-то функциональность в системе вендора присутствует, то он утверждает, что эта функциональность обязана присутствовать в базовой комплектации BPM. И напротив, то, чего нет в его системе, того и быть не должно!

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

Полный текст статьи: «A Short History of BPM». Sandy Kemsley, www.ebizq.net

— WJ 04.12.2006

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

«BPM, BPEL & SOA: A Comedy of Errors». Rob Risany, Director of Product Marketing, Savvion

Имел ли в виду Шекспир BPM, BPEL и SOA, когда писал свое бессмертное произведение? Шекспировская «Комедия ошибок» сегодня.

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

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

Комедия ошибок начинается, когда люди бизнеса ждут, что BPEL и SOA позволят им магическим образом изменять свои бизнес-процессы так, как требуется бизнесу именно сегодня. SOA и BPEL — это не для людей бизнеса. BPM — другое дело: BPM открывает компаниям возможности принципиально другие, по сравнению только с BPEL и SOA.

Так какую же роль играют BPEL и SOA в BPM-ориентированном предприятии? Представьте себе IT-ватерлинию, выше которой расположены интересы людей бизнеса. Здесь BPM задает общий бизнес-язык, что позволяет создать единое бизнес-пространство. Ниже ватерлинии — сфера IT-департамента, обеспечивающего реализацию SOA-стратегии, индивидуальную структуру приложений и оркестровку. И неважно, будет ли эта оркестровка выполняться посредством BPEL или же использовать другие методологии.

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

Полный текст статьи: «BPM, BPEL & SOA: A Comedy of Errors». Rob Risany, Director of Product Marketing, Savvion, www.ebizq.net

— WJ 22.11.2006

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

«Введение в BPMS». David Mc Goveran

Что такое BPMS и что предлагают поставщики BPM-систем.

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

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

  • интерфейсы пользователя
  • BPA (Business process analysis)/M(Monitoring) функционал
  • исполняемые приложения
  • BAM (Business activity monitoring) и EPM (Enterprise performance management)
  • инфраструктура
  • администрирование системы

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

Статья написана в марте 2005 года, в русскоязычном переводе опубликована в октябре 2006 года (Перевод В.В. Репина). Несмотря на относительно «зрелый» возраст статьи, она актуальна и на настоящий момент.

Полный текст статьи: «Введение в BPMS». David Mc Goveran, www.finexpert.ru

— WJ 10.11.2006

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

«Введение в BPM». David Mc Goveran

Анализ развития взглядов на BPM

90-е годы прошлого века принято считать годами зарождения понятия бизнес-процессов. Однако, не многим известно, что более чем столетие назад Фредерик В.Тейлор (Frederick W. Taylor) опубликовал Принципы Научного Управления, в которых присутствовало «стремление к повышению эффективности бизнеса путем определения конкретных бизнес-процессов, к которым впоследствии будут применены „принципы научного управления“». Это ли не первые попытки реинжиниринга?

К началу 90-х идея повышения эффективности управления путем улучшения бизнес-процессов была активно воспринята обществом. Однако, основные идеи того времени сводились в большей степени к реинжинирингу, нежели к непрерывному улучшению и изменению процессов. И только в последние пять лет стала активно развиваться теория BPM (Business Process Management).

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

Термин BPM не является новым и развился из областей, связанных с бизнес-процессами, в т.ч. таких, как: улучшение бизнес-процессов, реинжиниринг бизнес-процессов (BPR) и инновации менеджмент бизнес-процессов. Отсутствие точного определения BPM порождает много неясностей при обсуждении этой темы. Поэтому в своей статье автор, Дэвид Мак Говеран (David Mc Goveran) дает формальное определение и описывает некоторые важные принципы BPM.

Поддерживающие технологии развились из более ранних технологий для управления потоками работ (Workflow Management), EAI, автоматизации процессов, интеграции процессов, моделирования процессов, оптимизации процессов и так далее. Большое число аналитиков или не выделяют различий между системой управления бизнес-процессами (BPMS) и системами управления потоками работ (Workflow Management), или рассматривают BPMS просто как способ управления потоками работ, интегрированный с инфраструктурой EAI или возможностями Web-сервисов. На самом деле такое определение явно сужает понятие BPMS.

В статье Введение в BPM Девида Мак Говерана, переведенной на русский язык и опубликованной на портале «finexpert», даны разъяснения некоторых базовых понятий, позволяющие получить представление о BPM и BPMS.

Полный текст статьи: «Введение в BPM». David Mc Goveran, www.finexpert.ru

— WJ 04.10.2006

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

«Combining BPM and SOA for Competitive Advantage». Phil Gilbert

SOA может жить без BPM, но с головной болью.

Перспективы сервисно-ориентированной архитектуры или SOA (Service Oriented Architecture) для многих уже очевидны. Возможность использования имеющихся в распоряжении компаний программных продуктов, адаптируя их к новым условиям хозяйствования, делает этот подход весьма и весьма привлекательным для многих директоров ИТ-служб. Объединяя данные из различных источников и отдельные функции в бизнес-процессы, компании получают возможность развивать новые направления, не тратя время на переделку старых программ.

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

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

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

В своей статье Фил Гилберт приводит несколько примеров того, как различные компании решают вопросы повышения эффективности бизнес-процессов. Небольшая реклама родной фирмы в конце статьи не портит общего впечатления.

Полный текст статьи: «Combining BPM and SOA for Competitive Advantage». Phil Gilbert, Chief Technical Officer of Lombardi Software, www.bpmg.org

— WJ 16.08.2006

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

«Spreadsheet and BPM, continued»

Чему BPM может научиться на опыте других технологий.

В продолжение заочного разговора о параллелях между электронными таблицами и BPM, (который мы уже пересказывали), David Ogren в своем блоге высказал еще несколько мыслей:

Развивая тему параллелей между BPM и электронными таблицами:

  • Не должно быть дистанции между моделью процесса и его реализацией. Только представьте себе следующую картину: аналитик отправляет свою электронную таблицу программисту, тот импортирует ее в какой-то свой инструмент и компилирует в exe-шник. Ни один нормальный человек не стал бы пользоваться электронными таблицами, если бы ему приходилось через это проходить. Те же чувства я испытываю по отношению к BPM-системам, которые требуют преобразования от «модели аналитика» в BPMN к «модели разработчика» в BPEL — это чистое безумие.

  • Для бизнес-пользователей важны короткие итерации, получение быстрого отклика в ответ на вносимые изменения. Когда бизнес-аналитик меняет схему процесса, он должен иметь возможность немедленно ее проверить. Во-первых, это помогает быстро освоить инструмент, во-вторых, позволяет быстро продвигаться вперед, не ввязываясь в длительный цикл интеграции и тестирования. (Добавим от себя: технари-разработчики тоже, и уже давно, пришли к выводу о предпочтительности короткого цикла разработки перед классическим «водопадом». Для них точно также важно возможно быстрее получить отклик пользователей.)

  • Отдел ИТ не в состоянии контролировать все на свете. Большинство таблиц Excel — это уродливые поделки. Но они работают и они «достаточно хороши» для бизнес-пользователей. Да, было бы неплохо иметь библиотеку повторно используемых электронных таблиц, а в нем эталонную таблицу плана продаж. Было бы совсем замечательно, если бы каждое подразделение ею пользовалось. Но в каждом подразделении руководитель организует работу немного по-своему, и именно поэтому все вокруг составляют план продаж при помощи Excel, а не соответствующей функции CRM-пакета. Вывод: мы обязаны относитьтся к процессам как к ценному активу, но в то же время мы должны признать право подразделений на принятие собственных решений в том, что касается их собственных процессов.

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

Далее автор рассматривает параллели между BPM и Business Rules Engines, а также BPM и порталами — с ними мы предлагаем нашим читателям познакомиться самостоятельно.

— АБ 25.07.2006

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

«On Defining “Workflow”»

Говорим “Workflow” — подразумеваем BPM?

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

Так что же подразумевают сейчас, когда говорят о Workflow?

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

Не так давно мы публиковали на сайте статью Анатолия Белайчука Зачет по BPM, в которой этой проблеме был посвещен один из разделов. Теперь появилась возможность сравнить его точку зрения с мнением других аналитиков.

То, что это мнение не у всех одинаково, это не удивительно. Разночтения возникают не только между отдельными людьми, но и между разными вендорами.

Об этом пишет в своем интернет-блоге Дэвид Чаппел, глава консалтинговой компании Chappell & Associates.

Сравнивая высказывания Кейта Свенсона в его посте “Workflow” is Back и реакцию на него Брюса Сильвера Is Workflow “Back”? (Did It Ever Go Away?) Чаппел соглашается с ними, что правильнее всего называть термином Workflow автоматизацию взаимодействий между людьми. Если разделить понятия Workflow, относящееся к автоматизации действий людей, и Orchestration, фокусирующуюся на взаимодействии между системами, то можно сказать, что BPM — это «зонтик» над ними.

В то же время, Чаппел весьма скептически относится к тому, что Microsoft использует термин Workflow в ожидаемом вскоре Windows Workflow Foundation. Поскольку, с одной стороны, этот продукт будет использоваться для H2H интеграции в добавок к Windows SharePoint Services, Ver.3 и Office SharePoint Server 2007. Но также он будет использоваться для system-to-system интеграции, когда однажды BizTalk Server получит возможности оркестровки.

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

— WJ 24.07.2006

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

«The Forrester Wave™: Enterprise Service Bus

Рейтинг ESB-вендоров от Forrester.

Forrester Research опубликовал рейтинг поставщиков на рынке Enterprise Service Bus (ESB). По результатам исследования, включающего в себя более 100 критериев, номинальными лидерами названы Cape Clear Software и BEA Systems, вплотную к которым расположились Software AG, Progress, IBM и IONA Technologies:

С полным отчетом можно познакомиться:

  • тем, у кого есть лишние $795 — на сайте forrester.com
  • остальным — на сайте softwareag.ru

Спрашивается, при чем тут BPM? Вот определение ESB, которое дает Forrester:

Infrastructure software that makes reusable business services widely available to users, applications, business processes, and other services.

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

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

Полный текст статьи: «The Forrester Wave™: Enterprise Service Bus, Q2 2006». Ken Vollmer, Mike Gilpin, Forrester Research, Inc., 2006 г.

— АБ 18.07.2006

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

«What BPM can learn from a Spreadsheet»

BPM — это Excel сегодня?

Каждый, кто сталкивался с использованием компьютера «в полевых условиях» — в заводоуправлении или в офисе торговой компании — знает сколь огромное число мелких, но нужных задач решаются бессчетными таблицами Excel, которые создают сами пользователи. (Кстати, в результате даже появился специальный термин для обозначения таких пользователей: «power users».) Профессиональные программисты могут сколь угодно морщить нос — дескать никакое это не программирование — но факт остается фактом: если бы не эти «не-программы», то на программистов свалился бы такой вал заданий, от которого им самим стало бы плохо.

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

И это одно из обещаний, которое дает технология BPM. Насколько эти обещания реалистичны?

Так совпало, что сразу несколько светлых голов задались этим вопросом, и это вылилось в настоящую дискуссию между их интернет-блогами, интересную не только аргументами, но и личностями участников:

  • Tom Baeyens из команды jBPM, OpenSource BPM-системы, выступил с тезисом о том, что бизнес-анализ и программную реализацию в принципе нельзя объединить.

  • Keith Swenson, босс команды Fujitsu Interstage, одного из лидера рынка BPM по оценке Gartner, ответил следующей аналогией:

    Многие BPM-системы, ориентированные на автоматизацию работ, выполняемых людьми (в том числе Interstage BPM), дают возможность бизнес-пользователю нарисовать последовательность шагов процесса, описать эти шаги на естественном языке, ввести простые формулы, определяющие исполнителей, определить набор переменных для хранения контекста и позволяют сразу после этого запустить процесс на выполнение. То есть программирования в традиционном смысле тут не требуется вовсе, но программирование присутствует в том смысле, в котором пользователь программирует, когда создавает таблицу Excel.

  • Его поддержал David Ogren из BEA, который развил эту аналогию дальше:

    Большинство пользователей Excel пользуются самыми простыми операциями над ячейками. Однако есть бизнес-пользователи, научившиеся пользоваться статистическими функциями, логическими переходами и графикой. Но даже «power users» понадобится помощь ИТ-специалистов для интеграции с базами данных. Стоит также заметить, что хотя создать таблицу Excel способен даже средний бизнес-пользователь, для того чтобы сделать что-нибудь по-настоящему удобное в использовании, выдержанное в соответствующем стиле и доступное к применению, как правило понадобится участие ИТ-специалиста.

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

  • Bruce Silver резюмировал обсуждение:

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

Последний тезис — о размывании грани между бизнесом и ИТ — является одним из стержневых для BPM, поэтому неудивительно что Брюс высказался в ее поддержку. Но идея это одно, а что в реальности, приблизилась ли она к ней? Сам Брюс отвечает: «может да, может нет». Что ж, раз даже у гуру и архитекторов BPM-систем нет окончательной ясности, то не удивительно что столько копий сломано у нас на форуме («Легенда о том, как можно заменить программиста линейным менеджером или снова BPMS»).

— АБ 17.07.2006

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

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