Литература:

• Статьи
• Обзоры:    0    0    17    16    15    14    13    12    11    10    9    8    7    6    5    4    3    2    1  
• Форумы
• Стандарты
• Книги
• Авторы

BPM: хорошо или плохо для ИТ

"BPM: Good or Bad for IT". George Van Antwerp.

Я слышал много разных аргументов о том, какое будущее ожидает ИТ, и о том, какую роль в этом будущем будет играть BPM. Аргументы интересные, вот некоторые из них:

1. BPM не обязательно зависит от технологии. Да, но технология часто является частью решения.
2. BPM-технологии не могут обходится без ИТ. Не верьте обещаниям "no code" - о том, что бизнес сможет внедрить BPM без ИТ. Вам понадобится помощь ИТ-специалистов в инсталляции программного обеспечения, обслуживании, поддержке, интеграции, кастомизации и других традиционных работах (например, в управлении изменениями).
3. У ИТ и так полно проблем. Если что-то и может помочь, то это решения на основе BPM. Процесс - этот тот общий язык, которые способен сблизить бизнес и ИТ. BPM ускоряет развертывание приложений,  обеспечивает большую гибкость при их изменении. BPM прокладывает путь к управлению SLA. BPM вводит метрики и уменьшает число спонтанных запросов.
4. ИТ уже испытывает кадровый голод. Я слышал, как приводилась цифра 1.6% безработицы в ИТ. Поэтому важно все, что позволяет делать больше меньшими силами.
5. BPM на самом деле освобождает от необходимости участия ИТ в каждом изменении.  Это снижает вероятность крупномасштабного вовлечения ИТ в проекты. Проекты становятся меньше. Люди бизнеса получают возможность сделать намного больше.

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

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

Там, где пехота не пройдет

Крупные вендоры, поставщики BPM-решений, продолжают наращивать мощь своих платформ, добавляя все новую и новую функциональность к и без того богатым системам. Но стремление к гигантизму закрывает рынок BPM от среднего бизнеса. Опасение приобрести слона в посудную лавку подчас ставит руководителей такого бизнеса в сложное положение. С одной стороны, хотелось бы повышать эффективность управления, иметь больше привлекательности в глазах заказчиков, используя для этих целей современный инструмент. С другой стороны, большая и громоздкая система сложна в освоении и требует серьезных затрат на приобретение и эксплуатацию. Но главное - 80% функциональности "мега-системы" большинству компаний просто не нужно!

Дэвид Келли, вице-президент аналитической службы Hurwitz Group, по этому поводу сделал следующее замечание:

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

(Полный текст его заметки "Supersized BPM".)

Эта проблема "слонов" близка большинству российских компаний, которые испытывают потребность именно в легких, недорогих и гибких решениях. Этим отчасти объясняется популярность в России Unify NXJ - недорогой BPM-системы, которую можно к тому же и "потрогать руками", прежде чем принимать решение о покупке.

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

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

«Мысли о BPEL и XPDL»

Еще раз о стандартах в области BPM.

Шум, создаваемый в основном усилиями Microsoft, IBM и Oracle, привел к тому, что BPEL воспринимается как если не единственный, то основной стандарт в области BPM. В связи с этим представляют интерес две недавние заметки в ebizq.net.

Первая принадлежит Sandy Kemsley, известному аналитику в области BPM: 

«Assorted thoughts on BPEL» («Избранные мысли о BPEL»)  

Отмечая, что BPEL4People не продвинулся ни на шаг с 2005 г. и так остался в состоянии whitepaper, а также тот факт, что сложность BPEL не допускает использования его аналитиками, Sandy приходит к следующему выводу:  

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

С другой стороны, тем кто разрабатывает сложные сценарии взаимодействия веб-сервисов, возможностей BPEL не хватает и они возлагают надежды на зарождающийся стандарт WS-CDL: Web Services Choreography Description Language.

Во второй заметке с красноречивым названием  

«Is XPDL the Silent Workhorse of BPM?» («XPDL – рабочая лошадка BPM?»)

обосновываются следующие тезисы:  

• Из 10 стандартов, работа над которыми велась в 2003 г., сегодня, в результате прекращения работы над одними и консолидации других, осталось три: BPMN, XPDL, BPEL. Вопреки распространенному мнению, эти стандарты не конкурируют друг с другом. Явно отдельное положение занимает BPMN: это система условных обозначений и правил рисования диаграмм, доступная для понимания всех заинтересованных лиц – и бизнес-аналитиков, и менеджеров, и технических специалистов.

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

• XPDL был разработан WfMC для хранения и обмена диаграммами процессов между программными инструментами, один из которых предназначен для моделирования процесса, другой для чтения и редактирования, третий для исполнения процесса внутри BPM-«движка» и т.д. Примечательное отличие XPDL от BPEL в том, что он обеспечивает взаимно-однозначное представление для BPMN-диаграмм. Преобразование же из BPMN в BPEL является односторонним, аналогично компиляции из языка высокого уровня в машинный код.

• Иногда высказываемое мнение о том, что XPDL мертв или не относится к делу, свидетельствует только о плохой информированности. На сегодня XPDL поддерживает около 50 вендоров, включая таких энтузиастов BPEL, как IBM и Oracle, и 8 из 11 лидеров рынка BPMS по версии Gartner'2006. XPDL является стабильным стандартом на протяжении многих лет, и вы можете быть уверены, что XPDL V.3, когда бы он не появился, и инструментарий, который с ним будет работать, сможет прочесть те схемы, которые вы создаете при помощи XPDL сегодня. К тому же он общедоступен, не будучи связан никакими лицензионными ограничениями.

Не получая такой же шумной рекламы, как «некоторые другие стандарты», заключает автор Jon Pyke, XPDL молча делает то, что ему положено.

— АБ

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

«BPM, ISO & Six Sigma»

Как BPM соотносится с методологиями качества.

BPMInstitute.org недавно опубликовал две заметки на близкие темы:  

1. «BPM vs ISO», Stephen G. Smith, Senior Vice President & Managing Executive, Rummler-Brache Group.
2. «Can Six Sigma and Business Process Management Co-Exist?», Marvin Wurtzel, President, Marvin M. Wurtzel & Associates.

 Как известно, ISO уповает на документирование как на основное доказательство зрелости процесса. Отсюда – риск «липы» в сертификации по ISO: приложив усилия, компания может представить сертифицирующим органам замечательную документацию, которая, однако, будет слабо соотноситься с практикой ее деятельности. (Оказывается, эта проблема известна не только в России! – АБ.)

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

Многие компании рассматривают сертификацию по ISO как часть работы над брендом. Однако, если сертификация не отразится на продукции или услугах компании, то это может привести к цинизму и отторжению со стороны клиентов, в особенности если переусердствовать в рекламе факта сертификации. «Голого короля» клиенты распознают всегда.

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

Steve Smith замечает, что в некотором смысле, идеи контроля качества и BPM противоположны друг другу:  

• Философия BPM восходит к концепции «адаптивной системы», первоначально разработанной Rummler и Brache. В соответствии с этой концепцией компания, как живой организм, пребывает в состоянии постоянной изменчивости.

• Но если компания потратила серьезные усилия на документирование и шлифовку процесса (ISO) или на уменьшение вариаций качества (Six Sigma), то, в крайнем варианте, любая попытка изменить процесс в ответ на изменения требований окружающего мира будет встречать барьер сопротивления.  

В итоге Steve Smith, имеющий богатый практический опыт и в сертификации по ISO, и в BPM, приходит к следующему выводу. Усилия по сертификации в соответствии с ISO оправданы только в одной ситуации: если ее требуют ваши заказчики. Но даже в этом случае вы лучше распорядитесь своими ресурсами, если направите усилия на улучшение процессов, а документирование будете рассматривать как подчиненную задачу.

Marvin Wurtzel в динамические аспекты BPM не вдается, и находит BPM и Six Sigma вполне комплиментарными друг другу. По его мнению:  

• Сильная сторона BPM – способность автоматизировать выполнение процесса через анализ и моделирование шагов, входов и выходов. Но в том, что касается анализа, BPM не столь силен.

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

— АБ

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

«Эволюция BPM»

Можно ли считать, что рынок BPM определился, в какую сторону ему развиваться?

Современные BPM-инструменты создают отличные условия для управления бизнес-процессами. Как правило, это средства моделирования, среда исполнения, средства интеграции и анализа. Смещение акцентов в пользу того или иного компонента и является тем критерием, по которому BPM-системы можно отнести к разряду «человекоориентированных» (Workflow) или «интеграционно-ориентированных» (integration-centric), базирующихся на SOA. До недавнего времени разные вендоры активно развивали свои продукты, следуя одному из направлений. Но время и опыт показали, что наибольший интерес для потенциального покупателя представляет как раз вариант «два в одном» — сочетание Workflow с интеграционными возможностями. И поскольку законы рынка — вещь неумолимая, многие вендоры пошли на сближение (о чем мы писали в обзоре «Слияния и поглощения 2006 года»).

На сегодня список покупателей может пополниться за счет еще одного из крупнейших BPM-вендоров — компании Software AG, объявившей в апреле 2007 года о планах покупки webMethods, Inc. Правда, это объединение преследует своей целью скорее укрупнение, которое позволит компании Software AG претендовать на третью позицию в рейтинге крупнейших игроков SOA и интеграционного рынка вслед за IBM и Tibco. Но очевидно, что это не может не сказаться и на продуктах компании. Software AG, известна своими промышленными приложениями на базе SOA, включая CentraSite (совместная разработка с компанией Fujitsu) и Crossvision (лицензия от Fujitsu). В портфеле webMethods софт для интеграции, включая последнюю разработку — «Fabric™ 7 for Business Process Integration».

В одной из последних публикаций Paul Harmon, главный редактор BPTrends, привел список всех слияний, произошедших на рынке с 2002 года.  

Дата	Покупатель	Продавец
04-2007	Software AG (Platform)	webMethods (EAI)
11-2006	IBM (Platform)	Filenet (Documentation)
06-2006	EMC2-Documentum (Documentation)	ProActivity (BPMS)
03-2006	BEA (Platform)	Fuego (BPM engine)
12-2005	Intalio (BPM Engine)	FiveSight (BPEL)
10-2005	Metastorm (Workflow)	CommerceQuest (EAI) (слияние)
09-2005	Fair Isaac (Rules)	RulesPower (Rules)
07-2005	Seagull Software (Middleware)	Oak Grove Systems (BPM engine)
06-2005	Sun (Platform)	SeeBeyond (EAI)
04-2005	TeleLogic (Modeling)	Popkin (BP modeling)
06-2004	Oracle (Platform/Database/ERP)	Collaxa (BPEL)
06-2004	TIBCO (EAI)	Staffware (Workflow)
04-2004	Adobe (Documents)	Q-Link (Workflow)
09-2002	IBM (Platform)	Holosofx (BP Modeling)

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

— WJ 20.04.2007 

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

«The Forrester Wave™: Integration-Centric Business Process Management Suites

Forrester разделил всех участников исследования на группы:

• Лидеры: великолепная семерка. Обеспечивают сильный BPM и SOA. Это webMethods, TIBCO Software, IBM, Oracle, BEA Systems, Sun Microsystems и Software AG.
• Сильные исполнители: пять вендоров обеспечивают хорошие функциональные возможности для определенных сценариев. Сюда вошли SAP, Vitria Technology, Magic Software, Microsoft, Cordys
• Претенденты: iWay, сфокусированный на SOA.

И дал оценку каждому вендору отдельно.

Полный текст статьи: «The Forrester Wave™: Integration-Centric Business Process Management Suites, Q4 2006». Ken Vollmer, Henry Peyret, Forrester Research, Inc.

— WJ 20.02.2007

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

«BPTrends Survey of Business Process Initiatives». Nathaniel Palmer

• 22. Сравнение используемых метрик успеха по отраслям
• 23. Как определяется ROI эффективность и каковы ожидания
• 24. Временные рамки, использующиеся для измерения успешности проектов
• 25. Распределение расходов на BPM по категориям, как процент от проектных бюджетов
• 26. Распределение существующих расходов на BPM
• 27. Распределение ROI, измеренное после развертывания проекта

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

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

Полный текст статьи: «BPTrends Survey of Business Process Initiatives». Nathaniel Palmer, BPTrends

— WJ 08.02.2007

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

«What is BPM Anyway?». Mark Treat

Что же такое на самом деле BPM? Процессы, технологии или управленческая дисциплина?

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

• Процесс управления бизнес-процессами?
• Управленческая дисциплина?
• Технология или набор технологий?
• Среда для быстрой разработки приложений?

В первую очередь, это все же управленческая дисциплина. Поскольку любые технологии бесполезны там, где нет процессов и нет этой дисциплины. Наиболее точным можно назвать определение, данное Association of Business Process Management Professionals (ABPMP):

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

Многие люди путают Business Process Management (BPM) и Business Process Improvement (BPI) initiatives. BPI initiatives — это типичный проект, предполагающий одноразовые действия по улучшению имеющихся процессов. BPI включает такие методологии, как six sigma, lean, total quality management (TQM) и реинжиниринг (а-ля Майкл Хаммер). Организация, практикующая BPM, может применять у себя BPI, но это не означает, что те, кто применяют BPI обязательно практикуют BPM.

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

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

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

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

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

Полный текст статьи: «What is BPM Anyway?». Mark Treat, BPMInstitute.org

— WJ 22.01.2007

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

«What’s Wrong With This Picture, Redux». Bruce Silver

Что здесь не так? На старте здесь используется прикрепленное компенсирующее событие (compensation event) со стрелками, идущими от него к событию. Прикрепленное компенсирующее событие не может иметь исходящих стрелок, только ассоциированные (пунктирные линии) стрелки к одиночным компенсирующим шагам (compensating activity). Из прикрепленного таймера стрелка идет прямо на развилку (event-based gateway) Но это не BPMN, и не только из-за этого. Также из развилки не может следовать событие «None» (пустое), она должна куда-то пойти кроме окончания процесса.

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

Полный текст статьи: «What’s Wrong With This Picture, Redux». Bruce Silver, BPMS Watch

— WJ 19.01.2007

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