Постоянные упоминания о стандартах в 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
Комментарии
Много знает этот Синур У нас вот самые популярные стандарты в области бизнес-процессов до сих пор - IDEF0 и ARIS.
Не совсем ясен сакральный смысл дефиниции " UML... превосходит понимание большинства проектировщиков процессов".
Отец Синур соблаговолил бы до примеров снизойти. На агитацию за колхозы смахивает...
Леонид
Слово "дефиниция" Вы для красоты тут употребили?
По моему, все правильно Синур сказал. Пообщайтесь например с банковскими методологами. Максимум что они могут - это нарисовать чисто синхронный workflow. Даже BPMN в полном объеме, с исключениями и компенсациями, это для них барьер. А диаграммы классов и кейсы точно не для них.
Но, как говорил тов. Сталин, "другого народа у меня для вас нет". По-моему, надо дать бизнес-аналитикам инструмент, с которым они смогут эффективно работать, а не вгонять их в ступор тем, что способен переварить только ИТ-архитектор, да и то не всякий. Если загонять аналитика в UML, получите обратный эффект - он уйдет в MS Word.
Анатолий, слова "дефиниция" и "соблаговолил" употребил для красоты, так точно.
Благодарю Вас, что помогли разъяснить мысль Синура.
Первоначально я полагал, что проектировщики процессов это "венец эволюции" IT-составляющей бизнеса. Мне близка концепция Шеера. Если это так, то UML среди проектировщиков процессов популярный стандарт и уж точно, не превосходящий их понимание.
Что до бизнес-аналитика, то более поднаторевшая в экономике фигура, нежели проектировщик. Как минимум он не должен бояться в UML диаграммы классов и активности.
Но с поправкой на цитату классика, Вы с Синуром совершенно правы. Есл народ "грузить", здоровая реакция будет - "что не хочет быть понятным, то не следует читать".
Прошу прощения, изначально не разглядел, что цитату нужно примерить на наше фактическое состояние дел.
Извините за придирку, просто нет у Синура в тексте определений.
Кого называть проектировщиком процессов - на самом деле тонкий вопрос. "process/business analyst", "process/business/enterprise arhitect", "process developer", теперь еще SAP с подачи Силвера изобрел "process expert" - кто все эти люди? И ведь дело не в термине как таковом, а в том, что за разными терминами стоят разные концепции управления процессами.
А чем вам нравится концепция Шеера? На мой взгляд, если нет непосредственно исполняемой модели процесса, то нет и BPM. Если речь идет об автоматизации бизнес-процесса как о традиционном ИТ-проекте, то это опять-таки не BPM. Что бы не говорил по этому поводу уважаемый профессор.
Берите круче: в "BPM 101" (упомянутый тут на сайте тренинг) вообще приведена ссылка на BPMG 2005 BPM Research Paper, где перечислены (не поленюсь) роли: B.P.Manager, B.P.Analyst, B.P.Consultant, B.P.architect, Director BPM, B.P.Engineer, Process Engineering Manager, Process owner, B.P.Officer, BPM Project Lead. И если даже часть этих действующих лиц не сможет разбираться в UML, то понадобится, как минимум, еще "B.P.translator", для того, чтобы эти люди вообще понимали друг друга.
Но опасность основная даже не в этом. Реально граница проходит так: не-программисты (или "чистые" аналитики) и программисты (м.б. и аналитики, но погруженные в коды). Все, что между - примыкает либо к одним либо к другим. Как только бизнес-уровень позволяет процессу опуститься на уровень кодов, то тут нужно крепко держать свой конец веревки, поскольку как только процесс целиком окажется во власти программистов - считайте, что с этого момента вы им больше не управляете - реально это будут делать программисты. Именно поэтому BPMN - со всеми ее сложностями и наворотами - сейчас единственный способ для аналитиков удержать свой конец веревки. Все остальное - это уже в той или иной мере кодирование. Ну, или альтернатива - это BPM-системы, в которых если не BPMN, то по крайней мере нотации, которые их собственные движки понимают.
Юлия! В части того, что не надо давать "программистам" рулить бизнес-процессами - полностью согласен с Вами.
Я тут глубоко погрузился в Open Source сообщество, и с грустью для себя обнаружил, что в нём как раз рулят программисты (ну и те, конечно, кто "жертвует" им деньги...)
Поговорить о смысле, о терминологии, об архитектуре - не с кем (не с кем из тех, кто "рулит")...
Юрий,
я с большой опаской отношусь к Open Source продуктам. Это "а-ля то, что надо" - тут напильничком пройтись, тут молоточком... А что, тем, кто напильничком и молоточком - им платить не надо? Но при этом нет уверенности, что получится подводная лодка, а не паровоз (это в лучшем случае. В худшем - подводный паровоз ) А если эта штука собрана народным умельцем, то ее реального содержания кроме этого умельца никто и не знает. Возникает зависимость от умельца.
В юности мне привезли в подарок горсть золотого песка. Сказали: из такого добывают золото. Увы, золото добыть не удалось:( С тех пор я предпочитаю готовые изделия