Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

BPMN for People and Robots

How people activities look in various BPMN implementations? Let’s assume purely for illustration purposes that we have an “Inquiry to Order” process containing three activities: “Do This” (system), “Negotiate Contract” (human), “Do That” (system) and diagram it with several popular tools:

itp commerce Business Process Modeler for Microsoft Visio:


itp commerce  Process Modeler process diagram example

Unlike other tools presented, itp commerce tool doesn’t have execution engine, only simulation capabilities.

TIBCO Business Studio:

Swimlane name (”Sales Manager”) in TIBCO is just a label, it doesn’t affect the execution. The “real” participant is specified as activity attribute and isn’t displayed on the diagram.

Another caveat: TIBCO’s studio lets you model much more than TIBCO iProcess process engine is able to execute. Don’t be surprised by numerous errors when you try to upload the process diagram for execution - these aren’t BPMN errors but incompatibilities between studio and engine.

Oracle BMPS (aka BEA AquaLogic BPM or ALBPM):

Oracle BPMS process diagram example

ALBPM uses proprietary notation by default - you need to switch visual theme to get closer to BPMN. And still compliance to BPMN isn’t perfect.

But unlike in TIBCO, studio and engine are ideally coupled. Another nice feature: in addition to full-scale engines (standalone and J2EE-based) there is an engine embedded into studio. It’s very handy for analyst and developer to have a “sandbox” on his own computer for rapid process execution and verification.

The swimlane name “SalesManager” strictly defines the participant. It’s so-called abstract role which should be mapped to existing users/groups/roles at deployment.

And the “hero” of our parade, Intalio BPMS:

Intalio BPMS diagram example

A single rectangle transforms into four, connected with six arrows. Besides there are pools instead of swimlanes. I’m shocked. It’s 100% BPMN technically yet nothing but a mockery in essence.

It only may work in STP where a human is an add-on to 95%-automated process. Only if an exception occurs and a process goes off the mainstream s/he shall intervene.

But if we are dealing with a “normal” business process where a human does majority of activities - can you imagine what the process diagram will look like? A terrible mess. Just can’t imagine - how this can be offered to human beings? May be programmers would accept this - they are half-robots anyway :) but what about analysts and business people in general?

A note of the well-known independent analyst Sandy Kemsley published at Intelligence Enterprise “BPM Focus Turns to People in the Process” hits the point. Unlike me, she puts it politically correct and speaks about some “IT groups”:

“It may seem obvious that you have to consider the people who are part of a business process, but there are many SOA-centric IT groups that really don’t consider people as first-class process citizens. Rather, they are viewed as being there only to handle specific exception steps when things go wrong in straight-through processing.”

It’s a pity really. I feel sympathy towards Intalio as a company and I had certain expectations towards the product knowing that some colleagues use it successfully. And now - what a miserable disappointment.

From my point of view, the possibility for IT and business to talk the same language is not a feature but the classifying attribute of BPMS; if this “magic” is absent then other features don’t count. Unfortunately the way Intalio BPMS implements human activities make this system a pure IT tool even if they pretend to be very friendly to business analysts. I guess it’s because they are 100% BPMN-compatible. Yes they are but it’s BPMN for robots, not for business analysts.

I must admit that I’m still in doubt finding no cryticisms towards Intalio on this matter - may be I missed something? Let me ask you Intalio users: do you feel comfortable with this implementation of human activities? If yes - did you use some other BPMS and had a chance to compare?

02/02/09 | Articles | , ,    

Comments (32)

  1. st 02/02/09 03:07 PM

    а что Oracle со своим BPA и IBM?

  2. Anatoly Belychook 02/02/09 04:02 PM

    В каком смысле “что”? Oracle BPA - это лицензированный у IDS Scheer моделер, у IBM сразу несколько продуктов гордо носят лэйбл “BPM”. Вообще целью этой заметки не было представить исчерпывающий обзор BPMN-моделеров - это совершенно безнадежное предприятие, тысячи их!

  3. Dmitry Gusev 02/02/09 04:18 PM

    > Один прямоугольник превратился в четыре, и к ним добавились шесть стрелок. Да еще pool вместо ожидаемого swimlane. Воля ваша, но я пребываю в полном шоке. Причем что характерно: формально - 100% BPMN, по существу - издевательство.

    А представляете в каком шоке пребывает организация?
    Ведь в ее деятельности действительно каждой стрелочке/блоку BPMN от Intalio соответствует действие/документ.

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

  4. Anatoly Belychook 02/02/09 05:04 PM


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

    Разумеется, и в ALBPM, к примеру, вам тоже придется описать человеческую задачу более детально, чем просто нарисовав один квадрат. Но - и это очень важно - описание схемы процесса и деталей реализации шага, будь то системного или человеческого, в “правильной” (на мой личный вкус) BPMS разделены по уровням. Аналитик нарисовал схему из квадратиков - программист нарисовал/запрограммировал внутренности квадратиков.

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

  5. Dmitry Gusev 02/02/09 05:29 PM

    Лично я из этих диаграмм не вижу веб-сервисов вообще.

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

    > у Intalio и то, и другое вынесено наверх

    Опять же я не вижу, чтобы на диаграмме Intalio было видно программирование или что-либо с этим связанное. Программист может также как и в других случаях, как вы выразились, “нарисовать/запрограммировать внутренности квадратиков” :)

    Зато в случае с диаграммой от Intalio я, как аналитик, могу увидеть, с какими функциями ИС сопряжен этот процесс, а в первых двух случаях - не могу.

  6. Anatoly Belychook 02/02/09 05:52 PM

    Дмитрий, боюсь Вы не уловили суть дела. ОК, это я нечетко ее изложил.
    Как бы там ни было, нет тут ни 4 документов, ни 2 операций. Четыре квадратика на диаграмме Intalio - это фактически один шаг “согласовать контракт”, перегруженный сугубо технологическими подробностями:
    Negotiate Contract Before - это вызов веб-сервиса движка BPEL4People, создающего задание для определенного исполнителя.
    Negotiate Contract Create - движок генерирует форму для пользователя, получившему уведомление о задании и надумавшему его выполнить.
    Negotiate Contract Complete - пользователь выполнил задание, нажал соответствующую кнопку в веб-интерфейсу, движок BPEL4People посылает обратное уведомление в движок BPEL, исполняющее основное задание.
    Negotiate Contract After - движок BPEL стоит на этом шаге, дожидаясь уведомления от движка BPEL4People.

  7. Ismael Ghalimi 02/02/09 07:51 PM


    Great article, and very good points regarding the Intalio product, and it’s uncanny ability to make many things a lot more complex than they should be. We fixed it with the upcoming 6.0 release, to be made available later this week. Here is a screenshot of how Intalio|Designer supports human workflow patterns now, I think you’ll like it better than the old way:

    Best regards

  8. AS 02/02/09 10:48 PM
  9. Anatoly Belychook 02/03/09 12:10 PM


    Great to see your comments here. Thank you for staying tuned on customers’ concerns.

    So you hide human task implementation details into a subprocess. Good move - it resolves the major issue noted here and makes the business logic clear. The negative side effect if I got it right will be compromised subprocesses: now there will be “real” subprocesses and “pure technical” ones for human tasks.

    Anyway, let me wish your company a big success with the upcoming release, you must have hot time these days.

    Kind regards

  10. Anatoly Belychook 02/03/09 12:57 PM


    It’s OK to see human internals at hospital surgery but our case is like meeting a man on a street with his belly wide open :)

    I agree, Intalio makes a heroic job. However with all my sympathy to them I have a personal minimal set of requirements:

    1) The modeling tool must be simple enough for an ordinary business analyst being able to draw a process diagram - i.e. it shouldn’t be much harder to learn and to use than typical Visio drawing tool. Implementation details of either system or human tasks should be hidden e.g. in a separate “perspective”. Analysts don’t care whether it’s BPEL-based or not. The BPMN standard may permit using pools for internal participant instead of swimlanes to satisfy certain BPMS vendors needs but let’s get to the ground: swimlanes were invented by Geary Rummler long before BPM. We are not going to make an army of analysts forget their traditional vision and accept ours, are we?

    2) It should also be simple enough for an ordinary business person to read the diagram without systematic training. It happened in my practice several times that an executive pointed out a mistake in the process diagram presented by a team of analysts, consultants and developers. It saves you tremendous amount of time, money and efforts when it happens. And after all this is exactly “bridging business-IT gap”, one of the biggest BPM promises.

    3) Analyst’s and developer’s perspectives should be two layers of a single process description. No generation, transformation and/or conversion and roundtripping problem that they cause.

    4) Zero coding is a must for initital stages of BPM project. An analyst should be able to execute a process diagram without developer’s help. It means that there must me a kind of automatically generated prototype of BPM application. From my exeperience, this is the only way to validate the process model before investing into UI and system interactions development. Again, such validation can save you 3-5 cycles of your development which means a lot of time and money. The production system is quite different story: I don’t buy the idea of production UI made by a mouse click. I can see very clearly in every our project that end users need highly polished UI that can only be built manually.


  11. AS 02/03/09 02:12 PM
  12. Anatoly Belychook 02/03/09 03:39 PM


    Our concerns slightly differ: you are talking about the best BPM system one can think of while I’m only worrying about the best I can get from existing BPMS today or tomorrow.

    The time lag between DBMS and BPMS technologies is about 20 years - it gives the rough idea about when BPM standards may become stable. We are at 1989 of DBMS calendar today: SQL-92 is 3 years ahead and ODBC will become mainstream in 10 years. This makes me pessimistic about BPM standards to become stable any time soon. Is BPMN the last standard? I’m not sure and hence BPMN compliance isn’t the top priority for me.

  13. Dmitry Gusev 02/03/09 04:05 PM

    > Дмитрий, боюсь Вы не уловили суть дела. ОК, это я нечетко ее изложил.
    > Как бы там ни было, нет тут ни 4 документов, ни 2 операций. Четыре квадратика на диаграмме Intalio - это фактически один шаг “согласовать контракт”, перегруженный сугубо технологическими подробностями:

    Постараюсь изложить свой комментарий на английском, чтобы не показаться невежливым к нашим англоязычным коллегам :)

    Ok, I understand your point of view. But don’t you think the four steps are not just technological details which analyst can skip? I agree, there could be some implementation details like BPEL assignment statements that could be thrown away of the process’ diagram.

    But how would you tie your process with not only people involvled to the process, but with other IT assets?

    This is not such an obvious thing how the Sales from the example above will interact with the process. Sales doesn’t have any pluggable interface to control his behaviour.

    I mean, you as a process analyst should know exactly _how_ Sales will interoperate with the process, and this is meaningful for IT utilization also. Using such details from the diagram above I can see there is no some enterprise application involved to the process and this is a manual task.

    And, by the way, from this point of view it sounds reasonable to hide these implementation details to the subprocess.

  14. Anatoly Belychook 02/03/09 05:08 PM


    Sorry but you are broadening the scope of the discussion. All I wanted to show is this: *any* atomic human task transforms into 4 activities and 6 flows when implemented in Intalio. This is unacceptable from analyst’s perspective. The key word here is *any*, the content of the process example is irrelevant. If you admit that a process may have human tasks then you are in trouble; higher percentage of human tasks means tougher troubles.

    Please don’t be so focused on enterprise applications, interfaces, connectors etc. Let’s assume for example that there is an activity named “dig a hole in the ground”. Are you going to develop a computer interface to an excavator for this task? Come on, let’s better assign a human task to the manager carrying necessary information (where, how wide/deep the hole should be) and let him just press “done” button on the activity web form when it’s done.

    Generally speaking, neigther analyst nor process owner do *not* need to know exactly how sales guy or other employee performs his task. People aren’t robots - did you hear the term “knowledge worker”? And process management isn’t about this - it’s about the sequence of tasks, the outcome they provide and resources they consume, including time. As a process owner or analyst I don’t care whether he/she makes phone calls to the customer to agree the contract, meet him personally etc. on the condition that it’s done successfully under given time constrains.

    We can also talk about system activities and/or details of sales manager everyday duties but it’d be another topic.

  15. Keith Swenson 02/04/09 06:55 PM

    Consider carefully what is being modeled and what the purpose of the diagram is, and you will find a clue to how flexible and adaptable the diagram is.

    Many BPM systems are drawing a picture of the flow of bytes between systems. The diagram make explicit when a bundle of bytes is transferred from one place to another. You can theoretically model anything with a picture of the data that is sent and received.

    Other BPM systems draw a picture of the responsibility that the people carry, and purposefully hide the detail of how the information is transmitted around the system. In these systems a person will be assigned responsibility for doing a task, but the system then “takes care” of communicating this to the user, as well as allowing for a variety of different interaction modes. Consider an email message: you put the address of the recipient, but you do not have to specify exactly what systems send bytes to other systems: that is actually very complex and is a distraction to your goal.

    There is no right-and-wrong here: There are some people concerned about how bytes flow through the system and they want to be able to see that. But there are others who want to be able to easily represent and modify responsibilities; the detail of how messages are going to be sent is not just a distraction, but actually a hindrance to achieving their goals.

    While you are looking at how representations compare, you might want to consider this standard example process adopted by OMG ten years ago:


  16. Anatoly Belychook 02/05/09 12:14 AM


    Thanks for the link and for sharing your opinion here. But sorry can’t fully accept it.

    Sure there are people more interested in activities flow (let me call them analysts for simplicity) and those more interested in bytes flow (developers). Of course both aspects should be covered by a process model.

    Basically we have two options here:
    1) “tasks-and-bytes” diagram presents both aspects visually like Intalio does;
    2) “tasks-only” diagram models graphically only tasks flow and hides bytes flow elsewhere e.g. in task attributes or a screenflow.

    If we were robots then richer diagram would automatically mean better diagram so we’d take “tasks-and-bytes”. But business people and business analysts are unable to work efficiently with this kind of diagrams - at least those I know. So if we want to have them onboard we must take “tasks-only”. Developers may prefer “tasks-and-bytes” but they are able to use “tasks-only” too. So there is no symmetry.

    And if we don’t have analysts and developers in one team working on the same process model then we fall back to old good “process automation” with analyst-developer handout of paper process diagrams. Some people may call it BPM but isn’t it stupid to invent a new acronym (let’s pretend BPM is relatively new) and then use it for things we were doing for decades? For me, if it doesn’t help bridging business-IT gap then it isn’t BPM.

    – AB

  17. Julia Wagner 02/05/09 06:25 PM

    But who needs a diagram generally? Or rather, whether it essential for developer? He’ll go a back way more likely – at first will program actions, and then will present them in the form of the diagram to show them to analytics. Therefore if you are not care the processes should be design by analysts you should not be care of their existence at all. Then it is possible to tell simply: «hi, traditional program development, goodbye BPM!»

  18. Александр 09/04/09 10:35 AM

    Интересны Ваши публикации.Хотелось бы познакомиться с пракимчески реализованными проектами.Александр.

  19. Anatoly Belychook 09/04/09 11:04 AM

    Приходите на семинары, они задуманы как раз для разбора кейсов.

  20. Кузин Сергей 10/21/09 12:14 PM

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

  21. Anatoly Belychook 10/21/09 02:52 PM

    Сергей, простите, что значит “полагаю”? Попробуйте, убедитесь. Весь сюрприз как раз в том и заключается, что нельзя. Раз уж Ismael Ghalimi (глава компании) в своем комментарии это не опроверг, то наверное так оно и есть. Хотя некоторые шаги к улучшению положения они предприняли.

  22. Кузин Сергей 10/21/09 04:30 PM

    Попробовал, конечно, до того, как написать предыдущий пост - получилось.

  23. Кузин Сергей 10/21/09 04:37 PM
  24. Anatoly Belychook 10/21/09 04:45 PM

    Спасибо. Что ж, это конечно большой прогресс по сравнению с тем, что было в прошлой версии, с которой я экспериментировал. Как и обещал Исмаэль, они упрятали четыре шага в нечто типа подпроцесса. Но все равно получилось слегка извращенно. К примеру, с какой стати шаг “do that” становится активным сразу после “do this”?

  25. Anatoly Belychook 10/21/09 04:48 PM

    Второй вариант еще лучше. Остался один вопрос: зачем тут message flow, когда по существу это передача управления, т.е. control flow? Очевидно из технологических соображений. Впрочем согласен, с этим уже можно работать. Еще раз спасибо.

  26. Кузин Сергей 10/21/09 05:26 PM

    Насколько я помню, между пулами в BPMN взаимодействие между пулами как раз и отображается с помощью message flow. Так что первая картинка была “более правильной”. И мне кажется, что в задании “Do That” должно быть изображение задания. ожидающего сообщения (не нашёл в Intalio, но вроде бы есть в Visual Paradigm).

    Что касается control flow, то в BPMN 1.1 сразу попалась следующая цитата:

    BPMN does not use the term “Control Flow” when referring to the lines represented by Sequence Flow or Message Flow.
    The start of an activity is “controlled” not only by Sequence Flow (the order of activities), but also by Message Flow (a
    message arriving), as well as other process factors, such as scheduled resources. Artifacts can be Associated with
    activities to show some of these other factors. Thus, we are using a more specific term, “Sequence Flow,” since these
    lines mainly illustrate the sequence that activities will be performed.

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

  27. Anatoly Belychook 10/21/09 05:36 PM

    Конечно между пулами может быть только message flow. Только зачем тут отдельный pool?

    Я имел в виду sequence flow.

    Да, я использовал версию 5. Думал, Вы использовали версию 6. Пример сделан в соответствии с документом Intalio, описывающем как следует моделировать шаги, исполняемые людьми. Кажется я догадываюсь почему у Вас так просто получилось: нарисовать можно все что угодно, но не все движок способен исполнить.

  28. xtlan 10/21/09 10:13 PM

    Ну, реализация, конечно, вещь отдельная. :-) Хотя, если позволяет рисовать дизайнер, почему должна быть проблема с реализацией? Попробую проверить, и отпишусь.

  29. Gustavo Gomez 11/05/09 02:48 PM

    if you look at the BPMS out here you will find different paradigms in place:
    1. Some of them are Visual Programming tools: they were developed from an IT perspective, assimilating an “activity” with a “procedure” and defined its “parameters” as variables that go in and out of the activity (e.g., black box). Forget about bridging IT and business gaps and judge the productivity increases yourself.
    2. Other tools look at the process layer from the business perspective, and people are therefore first class citizens. Then they define how to aggregate and present them with the appropriate information so that they can perform their task more efficiently. This approach corresponds more to what you are looking for.

  30. Anatoly Belychook 11/05/09 03:06 PM


    Thank you for the input. Generally agree with your comment but I’d like to note that declared paradigm is one thing and implementation is the other. I guess there is no vendor not pretending to bridge “the gap” (BTW, it suddenly has become obsolete - the new talk is about “closing the gap”) and to treat human users with due respect. Yet even a brief look at the product sometimes says more than declarations - in fact this was the point of the original post.


  31. Александр 02/09/12 04:21 AM

    А что мешает в Intalio “нарисовать” процесс аналогично предыдущим примерам?

  32. Anatoly Belychook 02/09/12 08:47 AM


    Нарисовать можно - работать не будет.

Comments are closed

Copyright © 2008-2024 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments