Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Robots Don’t Talk To Humans

It’s common to see BPMN diagrams using send tasks to illustrate that we send documents to external entity and receive tasks to model obtaining an answer. Or (which is practically the same) using send message and receive message events for these purposes.

As an example - diagram from Russian Wiki:

Please don’t.

Both send/receive tasks and message events are “robots”, automatic actions. If there is a piece of software on the other side to then it’s OK: bytes go into the network connection to be received and processed on the other side.

But buyer is a human, you can’t “call” him as a web service! He communicates with us by phone, by email, by sending paperwork with courier - anyway it’s a communication with a human: our employee would receive email or documents, read them and decide what to do with the information obtained.

Therefore:

  • If the process automatically (i.e. pure programmatically, without human intervention) communicate with an external service then use service task, send/receive task and/or send/receive message event.
  • If the process automatically sends email then use a script task.
  • Otherwise do it with a user task because in the real life buyers, suppliers, partners, agencies communicate not with a process directly but via human participants.

01/07/13 | Articles | ,    

Comments (84)

  1. Дмитрий Бацюро 01/08/13 06:27 PM

    А как тогда корректно изобразить, что мы ждем отклика на наше КП, который может поступить в любой случайный момент после отправки КП клиенту? У нас же никто не занимается в это время задачей с неопределенной длительностью “Получить от клиента отклик на КП”. Т.е. ситуация не подходит под первые два пункта вашего перечисления “Поэтому”, а в третьем написано, что “только user task”. Или вы имеете в виду, что для полной корректности должен быть отдельный процесс “Разбор входящих”, в котором с какой-то периодичностью выполняется user task по разбору входящей почты от клиента, а вот оттуда в текущий процесс уже автоматически прилетает message event? Для исполнимого BPMN, согласен, это важно, но если процесс моделируется не для исполнения, а для осознания, то можно, я думаю, закрыть глаза на такие допущения.

    Кстати, по поводу роботов, общающихся с роботами - встретил тут где-то недавно аббревиатуру, входящую в моду: M2M. Обозначает взаимодействие “Machine-to-Machine”. :-) Но, кстати, системы межведомственного взаимодействия в рамках программы “Электронное правительство”, насколько я понимаю, примерно так и работают, как бы это ни называли.

  2. Anatoly Belychook 01/08/13 09:30 PM

    Дмитрий

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

    Если же разбираться с предметной областью всерьез, то тут два процесса: один заканчивается тем, что клиент акцептует (или не акцептует) наше предложение по формальным признакам; второй начинается (или не начинается), когда он приходит уже с заказом - может быть держа в руках наше КП, а может быть и просто так. Чтобы привести к этому эталонному виду вторую схему, надо переименовать процесс в “От обращения до КП”, последнюю задачу в “Отправить предложение” и последнюю развилку в “Предложение акцептовано”.

  3. Елена 02/25/13 05:20 PM

    Анатолий

    Вы пишете “Если хотите показать, что процесс автоматически (т.е. чисто программно, без участия человека) взаимодействует с внешним сервисом – используйте для этого service task”.
    Т.е., если в процессе предусмотрено обращение к АБС и соотв. возврат данных, достаточно использовать сервис таск, не нужно рисовать пул (или что это в схеме вики “Покупатель”) для АБС и использовать message flow для обращения?

  4. Anatoly Belychook 02/27/13 05:41 PM

    Елена

    Совершенно верно. Принципиальная разница между Покупателем и АБС та, что у Покупателя есть собственная воля. Поэтому ему нелья поставить задачу в рамках пула процесса. АБС - можно. К тому же оркестровка еще и проще - зачем усложнять без нужды?

    Отдельный пул для АБС и обмен сообщениями понадобятся в том случае, если это не просто синхронный вызов функции “запрос-ответ”, а нечто более сложное, асинхронное - см. последнюю пару примеров в http://mainthing.ru/ru/item/613/

  5. Cristian 11/24/13 05:11 PM

    Anatoly,

    I have read Bruce Silver’s book on BPMN2 and I have never found any description of a distinction between electronic messages and other kinds of messages. I find it really confusing to discover that different people with clear knowledge of BPMN2 give different meaning to the bpmn palette items. Is this distinction defined in the OMG document anywhere?

  6. Anatoly Belychook 11/24/13 07:02 PM

    Cristian

    BPMN is methodolgy-neutral notation - guess who said that? It’s Bruce’s words.

    Besides, it’s a classical example of “design by commitee”: it’s eclectic. On the other hand, it isn’t a big price for the broad acceptance BPMN has won.

    In practice it means that there may be dfferent interpretation of BPMN palette - different styles. Bruce made a great job but with all my respect it isn’t a holy book. While accepting most of it, I have different view on certain items - http://brsilver.com/bpmn-message-part-2/

    Interestingly, there are no process diagrams in BPMN spec like the one at the top of this post.

    So yes it’s confusing but it’s OK :)

  7. Cristian 11/24/13 11:05 PM

    Thank you, Anatoly. I respect both of you and did not try to imply his book is holy, just I needed to stick to one approach and I would have preferred to not have to choose between my two favourite bpmn evangelists :) sometimes bpmn drives me crazy because I feel it’s arbitrary. Some things I follow because one of you said so, but I am not comfortable with this. I want to know why it is that way, not just do it because one of the experts suggested. If I think of ERD diagramming, for example, everything is clear and all erd diagrams follow the same rules. But when dealing with bpmn, oh my God! Even the definition of human tasks varies between authors, slightly. I can sense the incomplete agreement between the members of committee in various areas, such as the ones described. I guess I need to stick to my liberties, as well…

  8. Anatoly Belychook 11/25/13 07:27 AM

    Cristian, I understand your feelings but you don’t need to trust someone blindly - didn’t I explain why a particular recommendation was made? E.g. people don’t talk to robots means that automatic activity of a process can’t communicate directly with a human and message event is a kind of automatic activity. Resort to logic, not to belief.

    As for ERD, “the most challenging in dealing with computers is dealing with people”. The big difficulty of BPM(N) is that it deals with people not less than with computer programs. ERD is far more technical hence it’s more straightforward.

  9. Cristian 11/25/13 09:45 AM

    Yes, I don’t want to trust anyone blindly, but when I try to make sense of things, sometimes there are contradictions between sources of information. Different people start with slightly different axioms and then conclusions diverge. My frustration comes from the fact the some things are not defined strictly enough by OMG, which means the standard has its dangling ends. Like a dictionary, where words have a definition to be shared by all people as a reference and synchronization of semantics. Otherwise, if I say horse and I think of chicken, one wouldn’t know what I want to say. But it is always very tonic to almost abuse your patient kindness :)

    Yes, you explained your definition of message event, but it collided with my knowledge coming from Bruce Silver and I did not know for which one to opt, in the end, because to some degree you convinced me, but on the other hand Bruce convinced me as well by emphasizing that message start event plays the special role of saying the current process instance represents the fulfillment of a specific request etc.and I assumed he talks from the spec, but… Because if there are as many options, the standard is a bit vague or incompletely defined. Discovering the standard convention may not be done by reasoning, it needs to be defined unambiguously. Can one use reasoning to find out the convention saying that in English the sequence of letters h o r s e mean an animal with four legs? I doubt…
    The reason I try to take your opinions and use them is you guys participated to the defining of standard and you may know things which are not even in the spec. When software companies, for example, develop software, they also provide some user manual, but that usually is incomplete. Then new authors come and give more background in books like “Unraveling the mysteries of Software X”. I treat you guys as one of those authors bringing more insight, which was insufficiently documented in OMG doc of BPMN.

    Sorry for the long paragraph…

    .

  10. Anatoly Belychook 11/25/13 10:17 AM

    BPMN is a loose standard, live with it.

    Therefore anyone has full righgts to develop his own style on the condition it doesn’t directly contradict to the spec. I’m considering myself as Bruce’s adherent. We have different views on certain aspects (most of them are summarized here - http://brsilver.com/bpmn-message-part-2/) but they are in fact minor. Alexander Samarin has yet another view which is probably farther from Bruce’s and mine (http://improving-bpm-systems.blogspot.ru/2013/11/practical-process-patterns-lifecycle-as.html).

    Bruce participates in BPMN committee, not me. I’m just learning and teaching BPMN for about 5 years and trying to summarize this experience. I didn’t write my book yet; blog is good but it lacks coherence.

    Getting back to the post, I don’t see a dramatic difference between Bruce’s and my interpretations, do you? I just attracted attention to the particular aspect that stayed in a shadow.

  11. Cristian 11/26/13 07:15 PM

    Bpmn

    What Bruce Silver describes as message start event in the blog is more detailed and, I dare to say, different from what he implies in the book. His blog makes some distinctions which I do not remember from the book. There is no difference between his blog and yours in this area, so I guess you both have the same take on this. He has examples in the book where a customer pool sends a message to another pool’s message start event. But a customer is not a robot…so Bruce Silver may have changed his mind in the meantime. I thought an event relevant to a process reflects something that has happened either in the process (and then a throw event is used) or outside the process (and then a catch event is used). Using this clear definition, it makes sense to me to just use message start event, whether or not the message is from robots or humans. If start message events are automatic, I guess in a manual process message events would never be used, just messages between humans and other pools made of non-automated activities as well. Is this how you see it? To me, events are things that happened, whether the process is automated or not. But if message event is only for robots, how to represent events coming from people? As a message only? If you read on page 26 the last paragraph, be says ‘In BPMN, the term message means any communication between the process and an external participant’. Well, any, to me does not mean automatic only. Later on, on page 27 he says ‘a message start event has special meaning in BPMN, and we will see it again and again. It signifies that a new instance of the process is created upon receipt of message…’. Then, on page 95 he says ‘The BPMN specification defines a message as simply “the content of a communication between two participants”. That communication could take any form. It does not have to be a SOAP or JMS message, as it might typically be in an executable process’.

    I know it’s not your responsibility what Bruce or others decide, but you can share with me your arguments so I can decide if they make sense to me or not. I just wanted to share my concerns and hope for some reply.

  12. Anatoly Belychook 11/26/13 10:02 PM

    “in a manual process message events would never be used, just messages between humans and other pools made of non-automated activities as well. Is this how you see it?”…or black box pools. That’s right.

    My argument is simple: events are similar to automatic task, whether it’s initiator or catcher. Now how can an automatic activity communicate with a human participant? It’s beyond my imagination.

  13. Cristian 11/27/13 09:22 AM

    If that’s the definition of events, it’s obvious I have to agree. Just I never found a clear definition of this distinction. Many BPMN authors threat events as both manual and automatic. Like in real life, events are things that happen.

    Thank you, Anatoly.

  14. Cristian 11/27/13 11:34 AM

    Anatoly,

    In the diagram above, ‘Clarify Request’ is a Human Task. Is this diagram for an executable Sale process? I assume it is.

  15. Anatoly Belychook 11/27/13 11:40 AM

    Cristian

    If it was an executable process, the black box pool and message flows won’t be depicted because there is no executable semantic in these elements. In fact they don’t add much value to the analytical diagram either.

  16. Cristian 11/27/13 11:54 AM

    Ok, then I have the next question. Since it is not an executable process, how come you are using a Human Task. I just re-read the spec and it says the human tasks are managed by a process engine and handled thru a task manager. Why not use Manual Task? I will stop here, but depending on what you answer I might ask some more stuff.

  17. Anatoly Belychook 11/27/13 11:58 AM

    It’s not a human task, it’s a user task. Human task is a possible implementation of user task via WS Human Task mechanism. Just one, most BPMS live without it.

  18. Cristian 11/27/13 12:07 PM

    I should have said User Task instead of Human Task because both manual task and user task are human tasks. The spec defines User Task as a task executed by and managed by a process engine. That is why I asked. If your process is manual, how can it have User Tasks? And here the only way out is to include in the User Task definition the user tasks executed outside the control of a process engine or task manager, but still thru the help of some software system. But spec does not really state this, unless you point me to that place.

  19. Cristian 11/27/13 12:23 PM

    I have also found a more relaxed definition in the spec: “A User Task is a typical ‘workflow’ task where a human performer performs the task with the assistance of a software application. The lifecycle of the task is managed by a software component (called task manager) and is typically executed in the context of a process.”

    I assume this is how you use it in your manual process above. However, I find the spec is dual about this, so a User Task is any task executed by a human using some piece of software, whether process engine and/task manger or not. I assume in the latter case the integrator between process and assisting piece of software is the performer himself, because there must be a relationship somewhere.

  20. Anatoly Belychook 11/27/13 12:30 PM

    User task assumes that there is some software infrastructure able to deliver the task to peformer and get back a responce. It may be workflow, BPMS, embedded social function within CRM… By contrast, Manual task is something that is done beyond the control of a computer-aided management system. In both cases the task is performed by human, the difference is in control. It doesn’t matter whether the task is performed in another computer system like ERP or by physical tool like a drill - it’s a human task anyway as soon as a human presses the keyboard or takes the drill in his hands.

  21. Cristian 11/27/13 12:35 PM

    So in your manual process above, the User Tasks: Clarify Request, Prepare Offer etc. are executed using some assisting software, right? Otherwise, you would have used Manual Task instead.

  22. Cristian 11/27/13 12:38 PM

    I think clarifying these things in a book (possibly your book, if you intend to) would help immensely your readers. Also, detailing the task assigning mechanism in the above diagram would make things so much clearer, in my opinion.

  23. Cristian 11/27/13 12:41 PM

    I assume the reason you made your tasks User Tasks is in order to imply some software driven assignment mechanism. But what if the manual process above has a manual assigning mechanism?

  24. Cristian 11/27/13 12:43 PM

    How would you model the above before the computer was even invented? Using Manual Tasks?

  25. Anatoly Belychook 11/27/13 12:46 PM

    It’d be more precise to say they are orchestrated using some software e.g. BPMS or workflow, meaning that tasks are assigned, delivered and marked as done. The essence of the work may be done somewhere else.

    You may forget about Manual tasks at all - it’s an exotic construct.

    You are right - this is another hidden (or not well-explained at least) assumption of BPMN. Thank you for asking “naive” questions - they help to identify these hidden things.

    As for the task assigning mechanism, I won’t agree. There are many aspects that should be considering when building a business process. Apart from the process scheme, there is data model, organization structure, business rules, assignation rules… One shouldn’t put them all into one diagram - it’d be a total mess. BPMN in particular is fitted just for the process scheme, and this one aspect alone is tough enough. It’s about what should be done and in what order, primarily.

  26. Anatoly Belychook 11/27/13 12:50 PM

    I’d say it isn’t about computer, it’s about a control system. In some organizations the office secretary plays the role of a process engine: passes the tasks to the right performers, gets back the results of their work and/or decisions, executes gateways using prescribed logic. Manual task is for some autonomous activities.

  27. Cristian 11/27/13 12:54 PM

    I am the one thanking you for your valuable help!

    I am still not clear what is implied the moment a User Task is used in a diagram. Some task assignment mechanism? Something else, like user is using some software to retrieve some info helping him/her to make a decision? This is where I am still unclear. If a user does not use any piece of software to perform their activity, what type of task would you use?

  28. Cristian 11/27/13 12:55 PM

    Or more precisely when to use User Task? In which cases…

  29. Cristian 11/27/13 12:58 PM

    Sorry for ’spraying’ your blog with one question after another…

    But in your diagram, the instance of process is initiated by the buyer. So who assigns the task to first User Task?

  30. Anatoly Belychook 11/28/13 12:03 PM

    Cristian

    I don’t try to cover all people’s communications in real world by a BPMN diagram, just formal activities perfomed within a process frame.

    It’s sales manager who starts the process. None start event is used meaning that its Sales manager’s discretion to initiate a process. It may be preceded by an unformal client’s request: “hey, can you sell this?”. So the manager initiates the process and the first thing he does is getting the details - exactly what items, quanitities and terms the client needs - hence the “Clarify request” task.

    Possible alternative - the client opens the seller’s website and fills the bying form. In that case it’d be a purchase order rather than a request. I’d depict it with a message start event and message flow getting not from a “Client” pool (human) but from “Website” pool (robot).

    Getting back to your question regarding tasks at pre-computer era, I’d change my mind. There were no “users” before computers where invented. Both user and manual tasks are performed by humans; the difference is that user task is performed by a human with computer (smartphone, tablets etc. also counted as computers).

  31. Cristian 11/28/13 06:17 PM

    I just asked what task type would you use to show a human does an action for a process from Middle Age? You cannot use User Task, can you?

  32. Cristian 11/28/13 06:18 PM

    Let me ask you another question. Or rather share an assumption. I think we model for the purpose of documenting and maybe executing the process in a process engine or software system. I write software myself. I try to write readable software. I modularize it. I do other things as well. But one of the main concerns I have when I write code is to make sure it’s readable and it does what is defined in the requirements. I do something resembling literate programming if you are familiar with Donald Knuth’s syntagm. My code tells a story. I write a story using a programming language as much as I can. Some people say the code is the most reliable documentation, facing humans when source code is read and facing computer processor when it is executed in binary form. The code does not have ambiguities at all. With minor exceptions, such as operator overloading in C++ etc. which causes occasionally bugs because of the very ambiguity.

    In the same way, when modeling a process, don’t you think it should above all tell the relevant aspects of process in a way that does not add too much noise and it should be done in a way which leaves littler room for subjective interpretation, ie it is not ambiguous. If you agree, then I ask you how can that be achieved when the graphical symbols expressing a process allow for so much almost arbitrary interpretation? If there is anything that chases people away from BPMN, I dare to say it is this very ambiguity before other difficulties. I now it’s a loose standard, you mentioned that, and I am not sure I know what it means. Let’s say I try to live with this. Does this mean that when somebody creates a diagram, the other readers of diagram have to have a loose understanding? Well, that’s bad. Because this has an impact on business. Can you live with loose reliability in your business? You can, but you will try better than just that. One way would be to have a clearer definition of concepts. And I don’t see how the committee agreements would be affected so much. There are just a few ambiguities there, I think. Besides, BPMN is not the first standard created by agreement. I think it’s doable. Or Bpmn will become (if it is not already) a collection of dialects. And then, like in Italy, people speaking southern dialects will have a hard time understanding people from other parts. Even tough they may claim they all speak Italian…

  33. Anatoly Belychook 11/28/13 09:18 PM

    Cristian

    Your concern is valid but fortunately there is a simple answer: any organization thinking about using BPMN efficiently must adopt or elaborate an internal agreement on its usage - a style, if you wish.

  34. Cristian 11/29/13 12:19 AM

    Thank you, Anatoly. I guess I need to come up with mine, as well, then…

  35. Cristian 12/02/13 02:59 PM

    Hi Anatoly,

    I was wondering how to decide when to choose to model activities of a process as subprocesses (in an orchestration) and when to model those parts as separate pools (collaboration). Any suggestions? I am working on a big process diagram and it has around 7 subprocesses, but each has around 5-6 activities. All activities are internal to some institution. There are occasional interactions with applicant. The process is about a property sale process thru cadastre office. I have the feeling that rather than model thru lanes it is better to model as multiple pools, roughly one for each subprocess. A subprocess is a process as well, so one pool per subprocess makes sense to me as well. This way the process is more manageable.

    Please, let me know your thoughts.

  36. Anatoly Belychook 12/02/13 04:55 PM

    Please don’t. I strictly recommend using orchestration as long as possible because it’s more straightforward. Of course if you care about your diagrams being perceived by business people. There should be sound reasons to switch to collaboration e.g. external events or group processing like in these examples: http://mainthing.ru/item/613/

    Your approach is also valid and have followers, so once again it’s a matter of personal taste. I blogged on this topic long time ago:
    http://mainthing.ru/item/154/
    http://mainthing.ru/item/182/

  37. Cristian 12/02/13 05:33 PM

    Anatoly,

    Thank you so much for your super-fast reply! I will the the links you provided.

  38. Cristian 12/02/13 05:47 PM

    I have a huge diagram and I have a hard time printing it. Does Bizagi Modeler handle well big diagrams? How about printing them or exporting them to PDF or PNG or other format?

  39. Anatoly Belychook 12/02/13 05:57 PM

    Sure Bizagi Modeler can export to PDF, PNG and also to Word, SharePoint, Web, Wiki… as every decent modeler does. Just dig into top menu.

    Yet any good BPM diagram fits into one screen or one A4 page of paper, period. If it doesn’t then you probably missed the point at which the process should be decomposed into subprocesses.

  40. Cristian 12/02/13 09:53 PM

    Anatoly,

    My process is modeled as 7 subprocesses, each subprocess having on average 5 activities. But if I expand each of the 7 subprocesses.the diagram becomes big. How would you print it in this case? One printout of the process with collapsed subprocesses and then one page for each expanded subprocess? How do you handle these cases. I just expressed my possible approach.

  41. Anatoly Belychook 12/02/13 10:08 PM

    That’s right. With some exceptions, expanded subprocess are evil. We introduce subprocesses to isolate abstractions and to make things simpler. It’s lost when expanded.

  42. Cristian 12/02/13 10:14 PM

    Thank you, Sir.

  43. Cristian 12/07/13 08:05 PM

    When you consider Send task an automatic task, how do you make sense of the fact it has a performer attribute?

  44. Anatoly Belychook 12/07/13 08:09 PM

    What about service task, does it too?

  45. Cristian 12/07/13 08:13 PM

    Is it inherited from abstract Task?

  46. Cristian 12/07/13 08:16 PM

    And Task gets it from Activity.

  47. Cristian 12/07/13 08:18 PM

    The standard should have instead added this attribute only to those subtypes of Activity which were intended in the standard to be human performable. And then we wouldn’t blog on this at all :)

  48. Cristian 12/07/13 08:19 PM

    But so being, to me Send may have a performer!

  49. Anatoly Belychook 12/07/13 08:19 PM

    Every (ok, almost every) element is placed on some lane just because there is no other room on the page. Yet not for each element it is meaningful.

  50. Cristian 12/07/13 08:20 PM

    By the way, what is the value you see in making Send task an automatic task only?

  51. Cristian 12/07/13 08:24 PM

    But one may choose not to show lanes. With your help and based on my experience I will avoid almost always the lanes and I will use groups and annotations, instead. Actually, whether one uses lanes or groups, they should only be used on (subprocesses) having no subprocesses, ie leaf-processes, otherwise one is back to square one.

  52. Cristian 12/07/13 08:25 PM

    Comment 49 does not convince me much

  53. Anatoly Belychook 12/07/13 08:36 PM

    Guess I’ll have to live with it :)

  54. Cristian 12/07/13 08:39 PM

    Ok :)

  55. Cristian 12/07/13 08:51 PM

    The difference between showing message flows into and from User Tasks and using Send/Receive Tasks is that for Human Tasks the message flows indicate optional message flows. So to show that they happen always, one needs some annotation next to message flow. The Send/Receive Tasks, on the other hand, imply the sending and receiving must happen always in order for process to continue execution. I find it more convenient to have the task symbol by itself imply this, without resorting to annotations. However, as an argument for your interpretation of Send/Receive tasks being automatic is the fact that Camunda modeler only allows performer on User Tasks, but not on Send/Receive tasks. And Bernd Rucker from Camunda has participated to establishing BPMN2 standard. So you might be right…

  56. Anatoly Belychook 12/07/13 08:59 PM

    I don’t know anything about Camunda modeler except the name.

    It’s a pure logic: user task is just a screen form (or a screen flow). Messages are auxiliary comments here.

    On the other side, everything else is not a user task hence it’s automatic in one way or another.

  57. Cristian 12/07/13 09:01 PM

    But Bizagi people, who also support BPMN2, allow the performer on any task, so they blindly follow the spec which allows performers on any Activity. To them, even a subprocess may have performer, which I find funny. I think it is all because subprocess is also an activity. But, if you go to your example related to state machine, a subproceses may be made of events and gateways only. In my opinion, subprocesses as well should not have performer. If they are made of any activity such as a User Task, that is the one that should have the performer set, not the container subproceses. I love the BPMN2 spec! It’s written by poets, I guess :)

  58. Cristian 12/07/13 09:09 PM

    I like your clear distinction between User tasks and everything else. But, I wonder, how do you represent the reaction to a signal that an event has happened? You are forced to use events. But then how do you represent the fact that some human reacts to an event? I think this is what gives most discomfort, plus other things I will not elaborate on yet.

  59. Anatoly Belychook 12/07/13 09:09 PM

    Don’t be so strict to them - it’s nothing but a regular price for a broad consensus.

    I agree - BPMN allowing performer for any activity i.e. a task or subprocess - looks silly. But it seems to be a tradition - the BPM CBOK by ABPMP put its the same way: end-to-end process decomposites into a sequence of workflows each belonging to a single business unit. I can’t accept this either.

    If it was my decision I’d allow performers for user, manual and service tasks only. Even script tasks don’t need one, leaving alone business rules, events, gateways and artifacts.

  60. Anatoly Belychook 12/07/13 09:12 PM

    >> But then how do you represent the fact that some human reacts to an event?

    It depends - give an example.

    And let’s better use abstract “event” term instead of “signal” - the latter has strict meaning in BPMN, it can’t be catched by a human.

  61. Cristian 12/07/13 09:14 PM

    I don’t think you wanted to include service tasks in the list of ones that should allow performers, it may be a typo :)

  62. Anatoly Belychook 12/07/13 09:21 PM

    No it isn’t. I didn’t include script tasks intentionally yet a service task may depict e.g. an ERP procedure. I believe there is nothing bad in drawing a “ERP” swimlane and putting it there.

  63. Cristian 12/07/13 09:23 PM

    I used the term signal like a notification that something has happened, i did not think at all of signal event. But I agree I should avoid BPMN keywords unless to express the keyword meaning itself.

    As an example…let’s say you have a property sale. And the seller must go thru cadastre staff. The seller must apply and bring some documents to cadastre staff. Later on, during the processing of this sale, cadastre staff discovers they need some document corrections from seller. At that time, the process must pause after notifying somehow the seller about the issue and wait for seller to come. How would you model the wait in process and the arrival of seller other than using events? I guess you will suggest modeling this thru some User task performed by staff where there must be interaction with seller using mandatory message flows between user task and seller, right? Or…?

  64. Cristian 12/07/13 09:24 PM

    @62: Ok, got it now.

  65. Anatoly Belychook 12/07/13 09:34 PM

    It’s already here: http://mainthing.ru/item/613/ scenarios 1.1, 1.2.

    Why do you thing a message interaction and external entities are obligatory? For me it’s just a tradition and bad style in most cases.

  66. Cristian 12/07/13 09:38 PM

    If I got you, the way you would model a manual process and later on turn it into an executable one (it’s a hypothetical exercise of value to me!) is this: you would only use User tasks, message flows and gateways (excluding event-based ones!). I guess you could also omit start and end events, for consistency, but those may be kept as an exception and for clarity, especially if you have parallel branches, terminate end events etc. Then, when making the process executable, you would drop some of the user tasks for the tasks that were automated and instead would use some service tasks and events and event gateways etc. and keep the manual things as they were before turning manual process into an executable one. Am I assuming correctly?

  67. Cristian 12/07/13 09:39 PM

    @65: I think it ads info which is necessary in order to understand how it works. I consider a diagram a story-teller: as I follow it, I get the way the process works. Do you have another view on this?

  68. Cristian 12/07/13 09:43 PM

    @65; I think in order to understand the process, one cannot omit the interactions, they are part of the process, aren’t they?

  69. Cristian 12/07/13 09:47 PM

    I find of immense value taking a process, modeling it as manual process and then presenting the executable version of it, where various parts are automated completely and some of the humans executing something in the process would be replaced by some automated service and most of them would continue to exist as User tasks, managed by the process engine in conjunction with some (usually integrated) task manager. This is the perspective of a guy who keeps trying to learn and improve on BPMN2, guess who?! :)

  70. Cristian 12/07/13 09:49 PM

    I also think that when modeling the executable process, some interactions, which otherwise may be omitted, will HAVE to be present for the engine itself, anyway.

  71. Cristian 12/07/13 09:53 PM

    @65: but you used message events in 1.2. Is it an automated process?

  72. Cristian 12/07/13 09:59 PM

    How would you model the intermediate message catching event Payment Received and its corresponding message throwing event if it was a manual process?

  73. Cristian 12/07/13 10:05 PM

    I find this (@72) important because you interpret intermediate message catch/throw event (or Receive/Send task) as automatic, not manual.

  74. Cristian 12/07/13 10:08 PM

    @65: I assume you try to avoid showing interactions because they are more related to the ‘how’ of an activity and not to the ‘what’, which is what process logic is about, right? And process logic is about what to do next once an activity completes, based on its outputs into process logic.

  75. Cristian 12/07/13 10:12 PM

    @65: But sometimes the process logic, such as some following gateway, makes more sense if the interactions just before the gateway where shown, because otherwise the task name must imply the interactions and that would be too much,I guess. In that case, the question used to label the gateway makes more sense if in the show interactions some text was used to label messages etc.

  76. Cristian 12/07/13 11:09 PM

    Would you comment at lest on 66 and 72 when you have time, please?

  77. Anatoly Belychook 12/08/13 09:01 AM

    Exactly what do we mean by calling an element automatic? Does it mean it is performed by a software? Nope. Gateways are automatic. Do we use them in process diagrams designed for comuter-less execution? Sure.

    There is always a process engine behind a BPMN model. It may be a software engine or it may be a human playing the same role: route the workflow, execute handoffs, send/receive messages etc. More precisely, process participants work for the engine in turn.

  78. Cristian 12/08/13 03:13 PM

    But if gateways are ok in manual processes, why not accept message events as well? I was asking earlier how would you model 1.2 if it was a manual process?

  79. Cristian 12/08/13 03:18 PM

    Would you still use Payment Received intermediate catch event?

  80. Cristian 12/08/13 03:54 PM

    Would you use a User task instead of Receive Payment event?

  81. Cristian 12/08/13 05:29 PM

    Question of post 80 was rhetoric, because if you used User task instead of intermediate message catch, you would contradict what you say in ‘command vs respond’, ie that ‘get payment’ is not a task, but an event. But since I proposed to model the process for manual execution, according to your ‘robots don’t talk to humans’ philosophy, one can’t use message event. I find this a deadlock situation. Which makes me think of math demonstrations of some theorem using the approach of taking opposed conclusion of theorem as hypothesis and reaching some contradiction, proving this way the opposed conclusion is false, so theorem conclusion is true. My point is if we make some assumptions about the semantics of bpmn, and our assumptions lead to contradictions, then some assumptions -maybe our assumptions - are wrong. You may remember that math theories are often based on axioms systems which must, among others, be independent of one another and non-contradicting. I think this is not the case for many of bpmn2 assumptions. What I find surprising is that even Bruce Silver seems to have changed his opinion again, according to what I read in his book and according to what he ‘recommends’ now differently - according to Rowan’s last post found here:

    https://groups.google.com/forum/m/#!topic/BPMNforum/tbxh5MpKRxg

    I guess him, like all of us, constantly tries to make sense of bpmn’s multiflavored ambiguities…

    In my opinion Receive Payment in 1.2 should be a intermediate message event even when process is not executable in an engine. Which is different from your idea that message event is a robot. I think it may be both…or you have a problem, unless someone shows me where I am wrong.

  82. Cristian 12/08/13 05:36 PM

    And knowing how to model manual processes is not optional. I remember you also think at most 10% of all processes, the critical ones, must be turned into executables. The rest will be modeled as manual, right? The question is how?!

  83. Cristian 12/08/13 05:41 PM

    The problem I see in considering message event an automatic item only is that by classifying it technically, you take out its semantic from the manual process modeling. And then there is no way to express that semantic need in manual processes.

  84. Anatoly Belychook 12/09/13 07:57 PM

    Cristian

    You ask good questions.

    Indeed if e.g. a data-based gateway (automatic by nature) may be used in a process diagram intended for manual execution (humans performing process engine’s functions, including gateways execution) then why shouldn’t message events and event gateways be used, too?

    Yet there is some difference. Suppose we are switching from manual to engine-driven process execution. Ideally the process diagram shouldn’t change on the transition. And it doesn’t when it concerns data-based gateway. Yet if it’s about message events and message gateways then process engine would be unable to process a nonformal “message” like a phone call or unstructured email - only something like a SOAP.

    Therefore I’d prefer to utilize a none start event for a process instantiated by an unstructured message, whether it’s manual or engine-driven. (The semantic of the none start event is voluntary start by a user.) For the same reason I’d use a user task for unstructored messages awaited in the middle of the process execution - again, whether the process is manual or engine-driven.

Comments are closed

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