Linkedin: Top Down or Bottom Up ?

<question group="BP Group">
Top Down or Bottom Up ?

Do we begin with a Top Down or Bottom Up approach when starting with BPM ?
Trying to figure out how BPM works is like solving a giant jigsaw puzzle. You can approach it in one of two ways. Using the “top down” approach (Process Architecture) , you start with the image of what the solved puzzle should look like, and use this to decide which pieces to ignore and which pieces to search for. The other approach is “bottom up” (Six Sigma), where you focus on the individual pieces themselves. You study them for unusual features and look for close matches with other puzzle pieces. If you don’t have a picture of the puzzle’s solution, the “bottom up” method is sometimes the only way to proceed. Lacking a good framework for understanding processes, organisations have been forced to stick with the “bottom up” approach. This tasks is Herculean if not impossible, with a puzzle as complex as an organisational structure.

Imagine a jigsaw puzzle with several thousand pieces. Many of the pieces can be interpreted multiple ways, as if each had an image on both sides but only one of them is right. All the pieces are poorly shaped so you can’t be certain if two pieces fit together or not. Many of them will not be used in the ultimate solution, but you don’t know which ones or how many. Every month new pieces arrive in the post. Some of these new pieces replace older ones, as if the puzzle maker was saying, “I know you’ve been working with these old puzzle pieces for a few years, but they turned out to be wrong. Sorry! Use the new ones instead until further notice.” Unfortunately, you have no idea what the end result will look like; worse, you may have some ideas but they are wrong.



</question>


From my recommendations for building enterprise BPM systems
<quote>
4.6 Avoid the trap of the selection of “top-down” vs. “bottom-up” – use the “pinball” style

Another typical symptom of getting stuck in the design phase of your BPM system is the existence of endless discussions about the necessary “granularity” of the services:

“If we select a top-down style then we will create coarse-grained business-related services, but we are not sure whether such services are implementable or reusable. If we follow a bottom-up style then we will implement too many fine-grained services for which the business value is not obvious.”

Actually, any such discussion is misplaced at this stage. What should be discussed is how to build future flexibility into the enterprise BPM system which will allow the rapid and painless adaptation of services to increase or decrease their granularity. Small and agile improvements may be required in different layers – rather like the multiple refinements of a ball trajectory in a pinball machine.

This pitfall is extremely common, so take care! We think its root is in the traditional (vs. agile) development practices which aim to provide a perfect system straight away – in such a system all services shall have the “right” granularity.
</quote>

I agree about the analogy with puzzle. I used it for my business process modelling procedure, see http://www.improving-bpm-systems.com/pubs/AS-BPMDS08.pdf

<quote>
In some senses, modelling is similar to solving a puzzle – everyone has his/her own way, but there are a few practical tips, e.g. make the edges first, group together pieces with a similar colour or pattern, collect them into clusters, use the latter as “centres of crystallisation” and then fill in the rest. But, there are a few real-life difficulties: you have to do many puzzles at the same time, to use pieces from other puzzles, to cut new pieces, to optimise the number of pieces, to transform some puzzles, etc. It should be a lot of fun!
</quote>

Thanks,
AS