Thanks,
AS

I really enjoy our discussion. To be able argumenting with diagrams not just words I commented it on my blog: http://mainthing.ru/item/182/

= AB

Link to the diagram

The “I” system you refer to… oh, let’s just go ahead and say Intalio so that others can understand the conversation. Take a look at the new version. I’m not going to post a link here but I will write about it in the tools section sometime later this week. It supports both styles, exactly as you say it should. It’s not the most intuitive to create lanes inside the pools at this point, but I’ve heard this is being worked on.

Not to get into specifics for one particular vendor here, but you have to realize in any system what you are actually modeling is the executable portion. For example, systems that only support one pool with many lanes are implying that they are human centric workflow, with some system capability. Again, I’d prefer not to mention names here but feel free if you know which systems I’m referring to. On the other hand, there are other systems that are SOA based for services orchestration. This approach usually requires a pool based modeling because all activities have a data scope similar to how pools work. Then you have some systems that have capabilities for both styles, in which you can use any diagram style you like if it suits the need.

There are many systems that require technical skills to use it, and there are just as many systems that are “watered down” and have restricted execution capability because they are so simple to use that you cannot easily integrate with other systems. I’m not saying that one approach is better than the other. You always need both IT and BA resources involved in every full scale project. I suggest the collaborative approach where IT and BA work together. But in a way you are right “without business analysts involvement any BPM initiative is doomed” because someone needs to drive it. And if the BA folks are not loving the tool they work with then it’s hard to keep things moving. For this I teach my BA students process modeling skills and tell their IT people to implement it. This works because when you have a good, well formed process model it’s very easy to make it executable on any system. And there won’t be anything lost in translation either because the high level and the intricate details of process flow and interaction are all captured in the BPMN.

Thank you for the detailed explanations of your position. I share a good part of it with a belief that a good process model is not a single-threaded behemoth but a choreography of relatively small (10-20 activities) process fragments, few swimlanes in each.

But I believe that 1) you go too far this way and 2) the tool shall not restrict you by one or another style but support both.

The link to the homework is in my original post. I found out that the only way to model human activity in BPMS we are talking about (let me call it “i”) is by creating a separate pool. As the result one comes to 4 activities and 6 flows instead of a plain simple human activity. Of every human activity.

I’d actually be very glad to be wrong at this point because this is the first, main and only reason why we don’t use “i”. With that level of complexity “i” is a product for IT people only and I believe that without business analysts involvement any BPM initiative is doomed.

=AB

You are right. I don’t want to negotiate with the clerk about well defined activity. But if I don’t own that activity and have no jurisdiction over how it’s performed, then all I can do is make a request and get a response. This is the true nature of the process, so I don’t want to insert any assumptions to the contrary in my process model. It’s all about providing accurate communication to people who read the diagram. I don’t want someone to read my diagram and assume that I have any sort of control over what the HR clerk does.

The “People” label, as pointed out by Sandy Kemsley, is better labeled as “My Organization”. But because the entire process is based on human interaction with no system involvement (or at least this is what the first two diagrams are implying) a logical way to group the activities while using this style is to call them people. Many BPM systems use this approach with a single pool I would consider to be called “human workflow” or “people” and then a seperate “system” pool for anything that is performed without human interaction. I don’t believe that I said it’s not legal to do in BPMN. I just don’t use this style because I prefer process models that offer a finer level of detail. In fact, if your BPM system is primarily workflow centric then there is nothing wrong with this approach, as it accurately depicts the primary participant – the system that the people log into. The actual people are not shown, but instead the user interface forms are shown. And again, back to the point of the post, it’s about understanding what exactly it is you are modeling and choosing the correct style for the actual behavior of the process.

I get your hint about “a vendor that promotes this view”. I can appreciate how you might see things that way, but let’s not go there. I remain vendor neutral on this site, and in fact I’m the biggest advocate for full BPMN specification compliance for this particular vendor. If you do your homework you’ll find that the vendor I believe you are referring to does in fact allow everything in one pool and using swimlanes. Two comments on this: 1) This is not the only system I use. 2) I’ve had the capability to use a single pool with lanes since October 2008 in this system. I still stand by what I say. Successful detailed analysis of executable processes is achieved through careful consideration of the various points of interaction between people, systems, and other processes. This has nothing to do with any vendor. I can do this same sort of diagramming style in nearly any system and achieve the same results. In fact, I developed this method while working for another vendor a few years back.

Your last point is also valid. But consider my points about exactly what a process is. I don’t believe that processes are totally linear. Layers exist in large processes. Often the subprocess shape is very underutilized. There is another style that I’m suggesting here that offers the best of both worlds – detail and high-level abstraction. When a geographic or departmental boundary is crossed, most likely you have another point of ownership. I’m referring to a long-term governance strategy. By placing abstracts of multiple intersecting processes in one view, I end up getting 10 stakeholders who take months arguing about how the process works before I get anything done. On the other hand I can get through a huge modeling exercise in just a few days by focusing on individual participants, while sacrificing that high-level overview. So you be the judge. If it’s more important to create a large overview process that everyone argues over or many smaller processes that fit together nicely, I get no arguments about them, but I cannot show a high-level overview. which is better? Both approaches have their advantages. The large view is the only way to see the entire process end to end with all the participants in place. However, the large view doesn’t offer detail and causes many opinions at the points where the lower level processes intersect. So what’s the best answer? I suggest that you should create both in order to tell the whole story.

I think we are saying the same thing here, but with a different style. The “silo” view you are referring to only exists when you don’t fully show the details of the other participants. I limited the scope of this posting for discussion sake, but as I’m seeing the comments I believe I should have expanded this out a bit more.

The approach I normally use is to model out the end to end process from the perspective of the primary participant. The secret to this is that the primary participant is not always a person. Sometimes it’s a BPM automation system, in which case all people are the contributors (secondary participants). In the example for this posting the Manager participant is the primary. This might not be the most perfectly optimized process but if this is how an organization is run, the process model must reflect the way the process works. Let’s just assume that I wouldn’t actually do it this way on a full scale large enterprise application.

I don’t understand why you say it would never be acceptable to separate the accounting process from the rest of this process. Let’s say for example that my accounting is outsourced. This is very common these days to have a third party payroll company that processes paychecks and does all of the payroll taxes. Are you saying I should include this in my process? I have no control over this third party, no visibility into their process, and no jurisdiction when it comes to change control of their processes. I think you get my point here. Now, how is this any different than using a large corporate accounting/payroll department? As a manager in my workgroup I have no control over what they do because the processes are governed by someone else and I have no jurisdiction or even a vote on how the process works. I simply participate with long-established process. However my process is not theirs either. So who is the owner here that I should assign? This is my point. There isn’t always one process owner. When you cross this boundary you should realize that more than one process might exist and you should leave it alone. It’s going to require another diagram not because it makes logical flow sense to do so, but because someone else owns that process and I have no control over it.

It’s perfectly acceptable to put as many pools within a diagram that you like. I try to limit this down to a reasonable, manageable number, which greatly adds to the readability of a diagram. But each of these pools can be further broken down into lanes if you like. For example, the HR pool might be further broken down into a lane to include “recruiter”, “candidate screener”, etc. I believe this would be completely acceptable because they are part of the same workgroup.

I don’t believe in putting everyone in the same pool because interaction takes place, and it’s important to show the points of interaction in the diagram. Otherwise I end up with a very simplistic high-level diagram that doesn’t acknowledge that communication exists, is if information flows from the brain of one person directly into the brain of another. There are subtle implications in a diagram that shows points of interaction that are highly valuable to show the true nature of the process. However it doesn’t make sense to use message lines for every point of communication. For my example in this post, let’s say that the manager works in a small workgroup isolated from the corporate office, and all communcation is done via email. Does this sway your opinion on how it should be modeled? Or should we just ignore the fact that an implicit participant (the email system) is involved in this process? So this is my point here. If I modeled everything in one pool with a bunch of lanes then many people would automatically make assumptions based on the over simplification of the process. I prefer much more detail, and this you cannot do with just lanes.

You are right: many people try to model an and-to-end process within a single pool and don’t know how to use message flows. It’s a well-known problem rooted in the lack of BPMN knowledge and skills.

However I believe that modeling all kind of participants with separate pools is another extreme, the truth is somewhere between.

My primary concern are human members of our organization participating in the process. Messaging is like negotiations: you send a message and the other party has a freedom in response. Control flow is dictatorship: you do this, they do that. A customer or a candidate should be negotiated indeed, but are you going to negotiate with a clerk about performing a well-defined activity within a process? As for me, I’d better give a direct order and use control flow to the activity placed into appropriate swimlane. No pools, no messages in this case.

Members of other branches in a global organization may be similar to external entity so this is a grey zone.

I’m sorry but your initial point that a pool corresponds to a single participant and hence the pool must be called “People” is misleading. You refer to BPMN but it’s rather your personal view and style. It’s legal yet other reasonable approaches exist.

I know one BPM vendor that promotes this view. They are just unable to execute a diagram without every human participant being placed into a separate pool – the approach your promote here by coincidence I guess.

Other BPMN-compatible vendors don’t have such limitation: you may put every participant into a separate pool and link them by message flows but guess what? People prefer to use lanes and control flows as long as the process stays within a single process/entity. Does such model produce robust executable BMP solutions? Sure it does.

=AB

Implicit in your approach is the old ’silo’ view of process that BPM is trying to eliminate. BPM is promoting an end-to-end concept of a process – for example ‘order-to-cash’ – to try and get away from the departmental hand-offs that so often caused sub-optimal process outcomes in the past.
The HR example you have used might be called ‘need-to-resource’ – ie the process that is initiated when the need for an additional (or replacement) person is identified and ends when someone is in place and provisioned to meet that need. Based on this view of the process, it would never be acceptable to say (for example) that the hiring process and payroll setup process are two different processes.
BPM advocates that a ‘process owner’ be assigned to the end-to-end process, not just the various bits of the process. With this approach, the former departmental silos become contributors to a unified process that delivers a useful outcome, not just a part of a process that in and of itself really isn’t much use.