Sorry, this entry is only available in Русский.

Somehow I got involved into the long discussion with Rick Geneva about best practices of process modeling and execution. Now after we’ve spent a lot of bytes at his blog it’d be fair to allocate some of my provider’s. Besides, after initial verbal firefight Rick resorted to the heavy artillery of process diagrams. Being unable to retaliate in comments at his blog I had to retreat to my own turf.

I spoiled Rick’s intention to remain vendor-neutral and eventually we came to studying Intalio’s way of using pools and swimlanes which I believe is… well… not quite obvious and not widely used. Yet it’s great for me to know how things are done with Intalio because I know several specialists who seem to be happy with it but couldn’t get the idea.

Rick presented a diagram of a simplified sample process where a manager wants to hire someone:

Rick comments:

The diagram style is a hybrid, which shows both the swimlane approach and the single pool approach that shows only the BPM automation system. In this case the primary participant is the automation system. However I could easily reverse this to have any one of my people participants to be the primary.

Now this is how I’d model the same process:

It differs from Rick’s diagram in many aspects:

• Pools are used for external entities and/or processes. “Candidate” is such an entity: we don’t control his process, all we have is a messaging protocol.
• There is no such thing as “primary participant”. There is a single swimlane in “Hiring Process” pool but it’s only because we simplified it to a bare minimum. In reality there would be also “Functional Manager”, “Security Officer” and maybe others. From my point of view, the idea of primary participant is bad: the process is supposed to break the walls between department walls. More participants, more separated they are in terms of geography and organization structure - more value one may expect from process management and BPMS.
• There is no such thing as “executable system”. For me it’s like drawing “DBMS” on a database diagram. 

Rick argues:

Systems that only support one pool with many lanes are implying that they are human centric workflow, with some system capability.

Sorry Rick, I have enough of this: one party call the other “some legacy workflow vendors” and they in turn call the opponents “webservices orchestration vendors”. OK, I draw this diagram in a modeler that doesn’t have execution engine yet I can see how it can be executed in Tibco, Interstage or Oracle aka Fuego. The key is engine’s capability to process messages flow - workflow can handle only control flows.

Anyone wants more pools? No problem, I can draw internals of the Candidate’s process:

Is the diagram better now? I don’t think so. The beauty of process choreography is loose coupling: the changes in one process does not affect the other as long as messaging interface is followed. One cannot achieve this with process orchestration as I noted in my previous post and I believe this is Rick’s point too.

Previous diagram lacks loose coupling so I’d rather draw the candidate’s process in a separate diagram:

I share completely Rick’s concern:

I suggest the collaborative approach where IT and BA work together.

But sorry Rick - I didn’t meet a business analyst that would accept your style, it’s too technical. So we fall back to the traditional way: an analyst draws some vague diagram then throws it over the wall to developers and they convert it into executable code that the analyst is unable to read.

And I don’t believe it must be that technical like it is in Intalio.

The current financial crisis isn’t a threat for BPM because there must be a boom before to talk about a crisis and there were no boom in BPM.

Some people anticipated the boom by calling BPM “The Next Big Thing”. Pure-play BPMS vendors have made big bids on the boom. The stack vendors aquired BPM assets.

In Russia, every BPMS vendor now has about one and a half BPM project - one successful and one decent - and shows them at every event. The first BPM conference in Moscow held in 2006 so companies invest into BPM marketing minimum for three years now. The results aren’t very impressive; not a boom anyway.

» read the rest

I critisized reengineering - in its radical form - many times both in public speeches and in private talks.

There was a temporary retreat from the concept of constant performance improvement during the reenineering epoch of 90’s. The technocratical, american, “cowboy” approach has won. Yet the idea of being able to draw the ideal business-process from scratch turned out to be too idealistic. First, cross-functional (enterprise-wide) business process are too complicated to be designed in one iteration. Secondly, there is no such thing as optimal “to be” - only a run to ever-escaping horizon.

Methodology, technology and organizational principles of BPM are based on these realities.

But… there is a nuance.

We conduct BPM projects for several years now and have a clean understanding of three conditions that should be met from a prospect’s side for the project to be successfull:

1. There must be a “pain”. Business must have a problem critically affecting it’s competitiveness and company’s prospects in general. And the problem should be identified - just an attempt “to do something” is no good.
2. There must be a will to solve the problem. Companies with degraded motivation - e.g. those where owners abandoned business completely, fully trusting to hired managers without a stock share - have problems at this point.
3. There must be resources: financial and intellectual. Minimal financial requirement is two full-time specialists, minimum one of them being internal employee. Intellectual resources means top managers being business process owners which implies in particular their readiness to spend one or two hours weekly to participate in process (re)design sessions.

Now, the first condition automatically means that the first step of your BPM project must be no constant improvement game but a radical redesign of the business process.

Why? Because “isn’t broken - don’t fix” principle is still in place. With very rare exceptions, no businessman would launch BPM initiative (as well as any other serious innovation) just because the life became too easy. There must be a performance gap for the project to be financially meaningfull. In simple words, one of valuable processes must be broken.

This way, we are back in reengineering, albeit on a new turn of evolution spiral. And by the way, “as-is” and “to-be” are also back in play - now we need them to quantify and measure process performance at project begin and end to tell the project sponsor exactly what he got for his money.

The bottomline: the BPM car in motion is constant improvement yet the starter of this car is one-shot, radical enough, reengineering-style process improvement.

Too bad I catched this only now when Michael Hammer has gone…

I can’t avoid paying my deep respect on this occasion to another titan that left us last year - Geary Rummler. He said in his interview (possibly the last one):

“I think there is only one critical condition for success that must exist – and that is the existence of a critical business issue (CBI) in the client organization. If there is no CBI (hard to believe) or management is in deep denial as to the existence of one, then serious, transforming BPM is not going to happen. Period. There may be misleading “demonstrations” and “concept tests,” but nothing of substance will happen. How can it? Serious BPM costs money, takes time, and can upset a lot of apple carts, and you can’t do that without an equally serious business case. I guess you could argue that a second condition – or factor – is that the internal BPM practitioner is about 70% a smart business person and 30% a BPM expert. Because the key to their success is going to be finding the critical business issue, understanding how BPM can address it, and then convincing top management to make the investment. I guess those are the two conditions: an opportunity and somebody capable of exploiting that opportunity.”

Thank you Geary, hopefully we’ve got the right course.

Sorry, this entry is only available in Русский.

Sorry, this entry is only available in Русский.

Another frequently asked question from a forum.

Question - When a business process template is modified (activity added/removed), what happens with process instances started by this template (previous version). What happens with analytics?

Answer - Most BPMS will finish running instances by following old template and will create new instances based on new teplate. It’s acceptable only if the template modification was planned. If - like it happens in most cases - the process became stuck because the template doesn’t have a desired gateway or a flow then you have nothing to do but abort the process instance and start it again by new template making the analytics inconsitent.

Yet there are systems allowing process scheme modification “on the fly”. Recommended reading:

• ebizq.net article by Glen Smith from Appian explains why this functionality is important from methodology perspective. You can launch the process into operations faster if you don’t have to discover details of all possible exceptions.
• Keith Svenson from Fujitsu notes that implementing process modification on the fly is hard to implement in a system that uses BPEL for excution. Fujtsu Interstage BPM lets you edit the scheme of a running instance the same way you edit a template; you can save the new instance scheme as a new version of the template if you wish.

Please refer to BPTrends report for the information about specific BPMS.

It’s hard to implement on the fly modification if a business process editor (modeler) is implemented as a desktop application which is the case for most systems. If a process instance stuck one should be able to correct scheme online promptly. Hence the modeler must be implemented as a thin client. Fujitsu Interstage for example has both desctop and online (java applet) modelers.

Oracle BPMS (aka BEA AquaLogic aka Fuego) took another way. The modeler pallette of this system has a special “magic” activity which can get control from any activity and/or pass it to any other acitivity. It solves the major part of the problem - absence of a desired flow on a scheme.

But you shouldn’t rely on a tool only - the process sheme should be designed the right way.

Let’s consider a long-term contract with a customer for example. We are going to deliver goods, obtain money and also renew contract’s terms and re-negotiate its conditions many times during several years. If we tried to implement it technically by a single process then for sure its scheme will be changed many times. Better solution is to create a long-living yet very simple process on the top level - a kind of a state machine keeping the state of our relations with the customer: “contract is beeing agreed”, “contract is in effect”, “contract is being agreed” etc. Every action starting from contract negotiations should be implemented by a workflow-like process. This workflow can be started if the contract is at some specific state and it can send a message to the contract process which will bring it from one state to another. Since the state machine is strictly passive one can modify a workflow scheme freely and/or create several alternative versions of e.g. delivery workflow.

BPMInstitute announced a presentation: “Secrets of a Business Process Consultant Shhhhh…Processes, Tools and Techniques that the Pros Use“. The presentation is too pathetic to me but one slide is worth to be memorized:

Have You Ever Heard…

• “You’ll need to come back when Sally’s here, she’s the only one that handles that.”
• “That’s the way we’ve always done it”
• “They don’t do things “our way”
• “That’s not my job”
• “They just sent me to see you, now your sending me back?”
• “Why are you making this so hard?”
• “You’ll need to go back to the _______ to get a signature”
• “I didn’t need this the last time I submitted…”
• “That department does it differently”
• “Well, whoever told you that was wrong, this is the right way.”

The same old question arose on a forum once again:

“In fact many BPM tasks could be solved with a document flow as well as with a DB. Yet results may not be very good…”

This is obviously a FAQ so I’m going to give a deailed answer, re-formulating the question for generality.

Question - What are the borders between DBMS, ECM and BPMS? How should they be combined?

Answer - Generally speaking we have:

1. structured information where DBMS excels
2. unstructured information (documents) is what ECM is for
3. process information is BPMS target

(BPMS uses DBMS internally and ECM may use DBMS or file system for storage but it’s beyond our scope.)

Every member of DBMS-ECM-BPMS trio is able to replace any of two remaining brothers but only some more or less nasty way:

• DBMS can store documents in text and binary fields yet it’s far from ECM functionality e.g. in navigation, content search, versioning, access control, MS Office integration.
• DBMS is sometimes used to store process information, usually in a table where each rows defines the next step of document processing. Of course it’s very primitive if compared with BPMS process diagram.
• ECM has a workflow or process engine yet it doesn’t match BPMS because of proprietary notation, platform, integration tools and what’s most important due to the lack of continuous process improvement methodology support. Simply speaking, a business process can be implemented in ECM but it’s hard to modify it with the speed required by business.
• Structured data can be entered into Excel file and stored in ECM.
• BPMS has typed attributes for structured data but clearly it’s for limited use only - the performance is nothing compared to that of DBMS.
• BPMS lets you attach documents to a process instance yet as well as in DBMS case, the service will be very primitive if compared with ECM. Besides there is a question: how are you going to reach your documents when the process has ended?

So if you are planning the perspective infrastructure then you’ll need all three components. On the other hand, if you face a task limited by functionality, resources and/or timeframe then you may look for a poor-man’s solution by compensating missing components with present ones.

Make your strategy balanced over time. E.g. BPMS document capabilities may suffice for a pilot stage of a BPM project. A pilot project should answer the question - “do we need all this staff at all?” - in the shortest timeframe. In case of positive answer we can add ECM afterwards.

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:

» read the rest