Is top-down BPM ready for the scrapheap?

When Valve created Half-Life they adopted the "Cabal Process", which according to Gabe Newell, President and owner of Valve Software, “the people involved were tired of working in isolation and were energized by the collaborative process, and the resulting designs had a consistent level of polish and depth that hadn’t been seen before.”

I decided to get in touch with Gabe directly following the last blog entry and find out his own opinions on hierarchy vs network organisational models.

“The simple answer is that hierarchy is good for repeatability and measurability, whereas self-organizing networks are better at invention,” Gabe said, “There are a lot of side effects and consequences. The lack of titles (roles) is primarily an internal signaling tool.”

“The alternate answer is that organizations that think they are hierarchical actually don’t gain advantage by it (they actually have hidden networks), and that the hierarchical appearance is the result of rent-seeking.”

So can we not redesign BPM and redefine an enterprise on the same principles and see the same effect but on a much grander scale ?

If we took adaptive case management principles and applied it to organisational makeup also then perhaps we wouldn't be discussing the over promise - under deliver scenarios Tom speaks of.

http://theopriestley.com/2010/02/28/hierarchical-incompetence-and-lateral-communication-the-support-for-collaborative-enterprise-communities/

But yes, traditional top-down business process modeling, even top-down BPM is dying in this new era. Once the last of the BPM dinosaurs stop practicing and preaching it then maybe we can move forward at last.

Strange question. Top down is the ONLY way to ensure that the operational processes being designed are aligned and consistent with corporate strategy.

Bottom up merely documents and then locks in the dysfunctional custom and practice built up over years.

End of.

I think in Theo's and Ian's responses you have the different lenses we look through.

On the one hand - if you're goal is innovation, top down is not a great recipe for that. Theo's mentioned this "cabal" process before (I swear, gaming companies are cool but does everything have to sound like it came out of dungeons and dragons?), and clearly these more innovation-focused approaches to process are near and dear to his heart and experience.

Ian, on the other hand, working with corporate clients of a more traditional sort (carphone warehouse i believe, for one), top down is the key - in fact it was all the "cabal-like" stuff that was probably getting these folks in trouble.

The thing is - you want innovation, but not in *every* aspect of your business. I don't want accounting getting too innovative, for example... or order entry... But when it comes to product design, or marketing - that's another story.

Interesting dichotomy, isn't it?

Declaimer: As there is no commonly-agreed definition for BPM (the community which should define BPM is happy with “…the definition of BPM will necessarily ‘emerge’ as market demands and technologies evolve”) my contribution is based on an BPM reference model - http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html

Statements like ”Is <particular>. BPM ready for the scrapheap?” remind me some chess players who said – we avoid using the queen and we are going to use mainly knights. Top-down, bottom-up, pin-ball, middle-out and etc. are very useful “chessmates” which can be used together. Of course, a proper architecture will help.

Thanks,
AS

Great response from Dr. Samarin, it always comes back to what an individual's understanding of BPM is. That aside I think any approach that attempts to be completely one-sided is doomed to fail. It's like taking a completely arbitrary position on something, rather than making a decision based on the facts.

Even if you believe in an approach that empowers workers to make their own decisions on how to execute a process at runtime (which I do), they still require goals and policies to be defined. They still require some sort of framework within which to work. In order for that work to be aligned it has to designed from the top down.

At some point your organization exists for a reason, it has a set of goals to which it works towards. These have to be deconstructed along process flows so that each component knows when their bit is finished and when the next begins.

The real change that is taking place is where you draw the line on the level of detail you take the process hierarchy down to. This will be different depending on the area of the business. In highly skilled and creative areas (e.g. R&D) only high level steps and goals are required. In high transactional, repetitive processes, then clearly more process detail is required.

What we're talking about is not ending top-down BPM but being realistic about the value that detailed process modelling provides.