Some of my favourite BPM Blogs

Here are my favourites. If I miss a good one, let me know!

http://improving-nao.blogspot.com/
http://www.column2.com/
http://www.brsilver.com/wordpress
http://www.ebizq.net/blogs/bpmblog/
http://kswenson.wordpress.com/
http://www.bpminaction.com/blog/
http://blog.lombardicto.com/
http://www.itredux.com/blog/
http://www.edmblog.com/
http://www.ebizq.net/blogs/it_directions/
http://blogs.ittoolbox.com/erp/bpms

Late at night - a small Godel, Escher, Bach thought on BPM

Ok, it's late, going to bed soon.
But I got triggered by a small sentence on
http://www.bpm.com/BriefingRO.asp?BriefingId=29
stating "the need for a tool to “manage the process of process management.”

Hm. Question to all BPM-people: how is the business process management of our business process management efforts....

If I read the sentence, it's almost like getting yourself out of a swamp, by pulling your own hair (that's an old fairytale reference :-)).

But seriously, is it possible to...
- Model your process management efforts
- Execute them
- Measure them
- Improve them
?

What KPI's can we define for process management efforts?
- Nr of models completed...
- Cycle time per model...
- Complexity of delivered models...
- Cost per model
- Nr of process issues identified. Nr of solved.
- Nr of process improvement ideas identified. Nr of implemented.
- Delivered business case
- Average business case per improvement idea

A big question is: can we define a model for, say proces modelling?
And interesting - if people feel awkward here, and doubt about the possibility to model the process modelling effort, well, how do you think your stakeholders feel if you come to model their process???? Right.

Good night.

Impressed ... new BPM technology and thinking

Today I watched the webinar, that you can access via http://www.lombardisoftware.com/press-release_2-12-07.php

Impressed...
- A nice but somewhat high level Forrester view on BPM

and then the new Blueprint solution of Lombardi...
- SAAS
- Collaborative process modeling
- Drawing done for you, by the tool, you can give activities in plain text
- Linking process issues and goals of the company - traceability of impact
- Roundtrip between the SAAS repository and your business location-based BPM engine, including BAM data

Hats off.

And a tip: quite nice other BPM related webinars available there!

Lean - Waste Part 2....

Another Lean Waste element is waiting time. Time where a customer request is waiting...
Let's go back to our insurance process, handling a request for a customer (a new insurance).

Do we have waiting time? You bet...
- A request waits in the mailbox to be picked up by the business and be distributed
- A request waits on an available employee to handle it
- A request waits because the company requested additional information from the customer (incomplete or incorrect)
- A request waits on availability and action of a internel employee, to provide internal information (a decision, a review)
- A request (or following subproduct) is waiting for an automated batch process that will process it further (typically during night, or weekend, or end of month).
- A request is waiting for a manual batch driven process ("once a day, in the morning, we empty the "send files" box, book the items and give it to our team).

Observations:
- If you walk around in the these types of companies, you can actually see these queues... Try to find large stacks of files or cases, on desks, bookshelves, cars, etc). In manufacturing terms, this is called Stock or Inventory (of work-in-progress).
- A lot of the more traditional data processing financial companies find this Inventory quite normal. Always been there, we always done it this way, "no inventory is red alert - people not busy enough...."

The true facts (and manufacturing consultants will find the following observations not that surprising):
- Each request that is waiting, is NOT adding value to the end-customer. The end-customer did not ask for waiting time, he or she asked for an insurance!
- Each request that is waiting, is costing the company money.
- Each request that would be processed faster, earlier, would lead to earlier cash flows.
- Earlier cash flows is greatly appreciated by your asset management department, and your shareholders

Essential reading for the BPM consultant...
The Goal - Goldratt
The Goldmine - Balle
And check out the Lean Institute.
Good reading, also for BPM-specialists, and also for services industries....

Lean Part 1 - On Lean's Waste Thinking in the financial industry

Lean is a nice framework to use to assess processes and redesign them...
One of the area's in which Lean shines, is the concept of waste: everything which is not supporting value in the process, towards customer and towards business.
If you apply this concept to typical data processing in financial service industry area's (such as insurance - claims, quotes, etc), you can see that some of the current industry practices can be done much more efficient...

Let's take an insurance company, and a request for a new insurance.

Let's start with a waste: Defects (e.g. a product has been produced partly or completely, but turns out to be defect, which means that the next step in the process can not continue and rework is needed).
Does this happen in our process? Yep...
- Supplied information by customer or agent is incorrect
- Supplied information by customer or agent is incomplete
- Customer request is being processed, but insurance company finds out that request is not within company policy
- Customer request is being processed, but insurance company finds out that request is not within company policy
- Customer request is being processed, but insurance company finds out that request is not within legal constraints
- Information stored or created by insurance company is incorrect
- Output created by insurance company is incorrect
- Output created by insurance company is correct, but not understandable by customer (Ouch! Know that one??)

Interesting enough - if you talk to the business of a company, these situations are very common. But then, if you ask them if these situations are TRACKED, the answer is usually no...
Ouch.... defects, but no clue on frequency, impact, cost, cause, structural fix/avoidance...
The second painpoint is the reaction to a situation. Typically an expensive employee (more experienced) will need to take a look, check, and correct. Expensive stuff. Again and again.

So, why not create the following business rules in every BPM process:
1. If a defect (situation above) is detected, the normal handler employee STOPs the process, records the event, and hands over the issue to a ERROR queue (with a seperate team), then continues on the next customer request. This keeps the normal FLOW going.
2. The error team analyses the situation, corrects the situation, if possible, or stops it. If corrected, the request is rerouted into the normal flow again
3. KPI's are defined on the error situations, measured and evaluated
4. Periodically, trend analysis and problem-cause analysis is done. Corrective actions are taken, to prevent or reduce situations from happening.

Process maturity starts with acknowledging wastes, including defects...

Alchemists and the search of the AS-IS to TO-BE

Having worked with BPR beginning of the 90's, I am glad that the industry has developed. One key issue that I experienced in the BPR area was the "Alchemist" movement (don't know how to give it a better name - people that through magic searched for a way to create gold). The alchemist were usually brought in when we as BPR team were done with the AS-IS modeling, and had also identified bottlenecks/process issues/etc. (In Hammer's time: the moment in the BPR project, where one should get a blank piece of paper and draw the TO-BE)
The alchemists would look at our models, look very intelligent, and draw the TO-BE. We would create a business case (again, magic...). We would simply start coding it in Client-Server :-). And the when change management time came along, it would work. The process. Well, sometimes.
And all the time, I had this nagging feeling... why this TO-BE process. Why not another.
Having some background in Operational Research/Econometrics, I would dream of applying some evidence-based/science supported framework, but people would laugh me away.
Well, time's they are a-changing.
As BPM specialists we should understand that magical TO-BE thinking is not enough.

There ARE frameworks, that have proven themselves, and we should know about them.
- Statistical process control
- Lean/TPS
- SixSigma
- Simulation
- TRIZ

Of course, the "makeable" business is an illusion. Even if we could design the "perfect" process, getting there is a whole new game. But it would not hurt trying to get a bit more logical and (services) science driven.

Page flow versus process flow

I started noticing that in a number of RFP's around BPM-suites a requirement start popping up, that can possibly create a lot of mess.

Requirement: "When a user is working on a workflow task, and finishes it through the task window, and the process engine determines that the following task in the same process instance is to be done by the same user, the presentation layer should automatically lock and open this task, without the user going back to the inbox".

Hm, it sounds like a logical and user-friendly requirement. But in already two technical projects, based on different BPM-technology, we have been trying to solve this and had difficult issues.
One of the key problems arising here, is the mix of two metaphores: the MVC design pattern for task based user interaction and the MVC design patters for workflow/process.

Because, suppose a BPM solution supports the stated requirement, well, then it won't take very long and then someone will happily say "he, but than we can use our BPM tool to model user interface flow, e.g. screen 1, screen 2, screen 3 or 4, including all business rules". Sounds nice. But don't go there....
Why?

1. Technical issue.
In a solid architecture, user interface and process engine are decoupled with clear interfaces. User interface can use the process engine API to...
- get inbox of tasks
- claim / open task
- park / pause task
- report task ready

Most BPM engines do not support an API call, where in one transaction, one can signal a task ready, let the process engine create the next task, and ask that task immediately if it's for the current user.... It means that if a user reports a task ready, and the user interface needs to know if the following task is for the same user, some type of polling needs to be done (because you do not want to have knowledge in the user interface about the process, aka ah, it was task 5 in process B, so than I know task 6 will be for this user again - this would give maintenance on too many places...)
Pooling would be tough - the user interface does not know: IS there a next task? When will it be there (the process engine might be busy)? When it's not there, does it mean there is no task in this process instance. Etc. etc. Difficult stuff.

2. Logical issues
What is a page? What is a task?
If you start mixing these things, projects could become very complex and you end up using technology for something it is not meant to be used for (as of yet...)

In my opinion is a task a logical unit of work, to be done by one user, in (preferably) one go.
It could require a user interface, consisting of multiple pages or windows. With complex business rules. But these are MVC task/presentation data business rules.

On content, process and relation...

In modern human interaction, there are basically three dimensions that influence the effectiveness of the coorporation between two (or more) people:
- Content (e.g. WHAT, the issue at hand, what do we want to reach together, solve, do, work on, etc)
- Process (e.g. HOW, in what way, through what steps, will we get to the objectives, and the required content, who will do what when why)
- Relation (e.g. WE - how do we relate, trust eachother, help eachother, like eachother)

Picture the following example situation:
Consultant is creating a beautifull BPM architecture (content).
Presents it to his key stakeholder.
Key stakeholder says "NO, I don't think this is a good BPM architecture...."
while thinking "because I don't trust you, and you don't seem to focus on my issues...."
Consulant says "Oh, I will try to improve the BPM architecture" while thinking
"Why is this architecture wrong, I worked soo hard, I dislike this person!"

I've been there.....
My lessons (learned the hard way):
- Be aware of these three dimensions (maybe there is even a fourth - spiritual, but that's an other story...)
- Realize that handling each dimension well requires different skills, and that skills of one dimension are often useless in the other dimensions (ever tried to create a projectplan (=process) to build your relation?)
- Keep the communication open - build the relationship for this, and when given feedback or decisions try to find out where it comes from (e.g. what dimension). Don't mix it up as the example person did (which was, of course, me....)

On serial thinking and case management

It's funny - how much people will start to think accoording to a tool metaphore, and forget reality. Dealing with business stakeholders, I typically walk through existing process documents (flows, diagrams, etc). During these sessions often we come to a certain proces, where a lot of steps are modelled, all done by the same user, modelled in a strict sequence, with a lot of business rules (e.g. research 1, if A, continue. research 2, if B, continue. etc.) Standard question: do you really do these in sequence?
Typically, the answer is... NO. A business person will do these in parallel, might skip a step, and will often have their own preference in which to handle first, and last. And usually, also the business rules are not done in sequence, but as a full-check.
E.g. the proces may look like:

Act1 -> CheckA -> Act2 -> CheckB -> Act3 -> Check C

And the business will do something like:
(In any order 1, 2, 3) -> (in any order A, B, C).

These leads to a number of observations:
1. Make sure that your model represents reality working
2. If something is not sequential, don't model it like that (even though it looks simpeler)
3. Wonder why sometimes users hate workflowmanagement solutions? Big chance they are forced to do things sequential, while reality or preference is different.
4. Try not to model all these rules in your process flow. Make it one decision case, and stick the rules in a rule engine....

Now, matters turn worse, if sequential oriented BPM modellers start trying to modelling processes, where the process is more a casemanagement business situation.
Casemanagement - difficult to define, but let's give it a try:
- Typical business process management solutions provide for production workflow - you can define a process template, and process instances will follow the process as defined in the template. There is always ONE point where the process instance is (except for maybe parallel tracks, but also there, there is always ONE point where the process-instance is, in that track).
- What if you have a situation, where the issue at hand (an order, a claim, etc), has a lot of different scenario's, which complicated timing dependencies and what-if's. For instance - a legal procedure, with many sidesteps, possible escalations and subprocedures. Trying to model that in a production workflow is seriously difficult - you end up with an almost unreadable diagram, with many many business rules, and not something elegant, agile and maintainable. Believe me, I've been there...
So.... what do we need? Technology that allows us to create unique process instances, where (in parallel) a user (or a system) can activate certain subprocess templates. A user interface that can help users with this (check out Flower, a dutch product).
And a modelling language that can support this. Ouch. We are talking state transititions, user selectable sub-templates, and still some way to know progress and termination. I would doubt BPMN is up to the task....

As observations:
- When you notice you are dealing with a complex business situation where production workflow modelling feels limited and create overly complex diagrams, you are probably on the wrong track...
- Don't try to squeeze a frog in a pan, don't try to squeeze a complex business situation in a too limited expression language such as BPMN.
- For now: create some kind of state diagram, an sub BPMN models + a lot of explaination :-)