Gary Comerford:

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the ‘whole level of detail’ issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

So true.  BPM depends upon building the right abstractions for your business, and business processes.  Getting to the right level of detail (rather than the lowest) allows us to build solutions at the right level.  When you see flowcharts covering a wall (or more than one screen in Visio) – the yellow flags are waving.  Slow down, caution.

James Lawther guest-posts on Gary Comerford’s Process Cafe Blog, and it is a piece we can really relate to at BP3:

In the beginning all businesses start out as small businesses.  They start with one, two or at most a handful of employees with a vision to give customers something new and different, or just better.  They then focus like crazy on those illusive customers, doing everything that they can to find and please them.
[...]
And then the company grows.

At BP3, we’re growing.  The trick, as they say, is not to lose that focus on the customer as the company grows.  Lawther’s advice?  “It is remarkably simple.  Get your business to re-focus on the customer and optimise around them not their functions.  And that is all business process management asks you to do.”

Even better – don’t lose that focus to begin with.  Easier said than done!

Gary Comerford of Process Cafe recently noted that improving process is not always in the company’s best interest, as in cases where penalties and fees may be extracted from uneducated customers and users.  Despite the following process issues for a train system, the organization may not feel that it is economically advisable to address them:

1) They are notoriously unreliable in their timings. Trains are late more often than should be expected
2) There are delays for many, many unknown reasons. Leaves on the line and ‘The wrong type of snow’ are two examples
3) The ticketing system is completely nonsensical and misleading.

Gary points out that the organization is not incented to address problem area #3.  That indeed, much of their revenues derive from the ticketing system’s shortcomings:

So let’s examine this: The process of a rail company calls for multiple, confusing fares which the customer has to decipher and understand. The penalty for buying and using an incorrect fare is a spot fine or the requirement to purchase a higher priced ticket to continue ones journey.

Can you see how improving this process would help the customer but not the company? They would end up with passengers buying the right fares, penalty fares being reduced and higher-priced ticket repurchases being eliminated. The end result would be a reduction in rail-fare income and associated profit. Of course the rail companies are not going to go for this.

I think this is a classic case of penny-wise, pound-foolish.  Of course it looks like the train system is making more money.  And initial measurements of revenue will tell them that revenues increased when they implemented the new penalties and schemes.  Based on this information they’ll proceed forward blind to the reality – that they are undermining the very foundation of their business – the goodwill of their customers.

When revenues eventually begin to decline, they’ll blame in on changing ridership patterns, changing economic conditions, etc.  They’ll never think to blame it on the fact that people would prefer not to use their service because it is a hassle.  When they need public-funded improvements in the rail line or station, they may be surprised when voters or elected officials fail to support them, further undermining their ability to serve customers well.   A difficult system also leaves people feeling that it is okay to cheat the system, because the system doesn’t seem to be fundamentally fair.

That said, I would differentiate between changes in the process that provide better customer service, and changes in the process that “make things easier for the consumer.”  Mortgage companies in the US made things easier for the consumer in the last decade- it turned out to be horrible for both the consumer and the business, in the long run.

Gary Comerford of the Process Cafe has a 3-part series on the State of BPM.  It’s quite a good read so far, into part 2.  And there’s a bit that particularly relates to what Bruce Silver and I were writing about earlier this week:

However, on the flip side many organizations remain “process ignorant” when it comes to BPM because many still don’t necessarily understand exactly how things are getting done in their own business. Some cited issues such as a lack of interchange standards between process modeling and execution tools, which can render system interoperability difficult. One reason that this issue exists is that organizations are using modeling-only tools that lack an execution component. Organizations are finding the breadth of available BPM systems confusing in that each vendor interface will dictate how business processes are to be designed and applied. Could it be that a single unified interchange system will prevail in the future which will allow any modelling tool to interchange data with any execution tool? The salesman at some of the larger vendors will tell you that this already exists, but seeing the number of forum questions that appear from developers who are building these execution systems, it is apparent that all is not totally well from this point of view. 

Yes, using model-only tools is fine – but one must understand that they start model-only and they end model-only.  When you move to execution, you start over.  Literally.  The good news is – usually – the original models don’t take that long to re-author in an executable model approach.

Interchange does not yet work to the satisfaction of technical users, let alone business users.  If the salesmen of large software companies are saying this they’re mistaken.  Some tools can export their own models to “BPMN2″ and import that same BPMN2 export back in.  This is not the same as importing the model from a third-party tool.  The “good” news is that all the vendors have at least a small motivation to implement importing.  The “bad” news is that none have any interest in building the exporters (I believe that will be up to the open-source community).