Are Organizations Developing BPM Solutions From a Top-Down or Bottom-Up Approach and Which is Best?

Personally, I think a bottom-up approach is best, since top down approaches have the tendency to "boil the ocean" slowing down the time until the field sees results. I think the adoption of agile programming methods shows that iterative design and working closely with the customer provides superior results to top-down waterfall type approaches. Given the current economic environment, anything that can provide a quick win in the field will be adopted faster then a top-down initiative.

I think this is especially true for human intensive processes. The ability to quickly provide value to the people involved without disrupting their daily work can be the difference between a successful or failed BPM project.

I don't think anyone ever develops business processes in an entirely bottom-up approach, since you have to have some idea of what you are trying to accomplish. So, the choice is really between purely top-down and a mix of top-down and bottom-up. We've found that the mixed approach definitely works best.

When you develop executable business processes in an entirely top-down manner, you ignore your company's existing software assets until you have the business process fleshed out in great detail. You then hand it over to IT and naturally none of the service activities in the process align perfectly with existing deployed services. When many processes are developed top-down, the development team ends up creating many similar services and the level of reuse within the organization is abysmal.

It is much better to involve the development team earlier in the development of the process. A high-level process can be sketched out, with many aspects described informally through documentation. Then once the development team is involved, the formalization of the process can be easily guided so that it meets the business goals for the process while also using existing software assets where it is appropriate to do so.

I didn't mean when creating a new process (which I think is unusual),but rather when using a BPM tool to automate (or semi-automate) an existing process. I think in that case it is better to use a bottoms-up approach (understand the real-world existing process) than to use a top down approach (using an idealized model of the existing process). Automated human process discovery tools are useful to help discover how an existing process actually works.

From my recommendations for building enterprise BPM systems

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.

Thanks,
AS

To Jacob: I have a few questions, which are a bit outside of the scope of "BPM tool to automate (or semi-automate) an existing process". The question is: how are you sure that the existing process is the right one to be automated? Did anybody challenged this process from the business perspectives? If I automate a process, why I do not automate a couple of 'related' processes to eliminate the whole 'process structure' and replace it by automated solution?

Anyway, when automating or creating process, the approach is always top-down because the first thing to be defined about the process is WHAT it is for, WHY we need it, and WHO will be using it. Only then we are getting to the definition of process actions and related business logic. A “pinball” style, mentioned by Alexander takes place after the top-down view on the process gets defined.

To Michael: To select what has to be improved (e.g. automated), a bigger picture is necessary. For example, see the slide #7 from http://www.slideshare.net/samarin/creating-synergy-between-bpm-and-ea-in-an-egovernment-environment

Also, Considering that a pinball machine launches all balls at the same direction, can the initial "always top-down" be integral part of the whole trajectory?

Thanks,
AS

I've always been a proponent of the Top Down approach, even for existing processes. The reason for this is the silo effect, in which the blinders are in-place for processes that use the bottom-up or middle-out approach. I've seen countless efforts miss the mark because they are starting out in the wrong direction when, if they had taken a step back (that is, Up), they would be able to see the context within which the effort is taking place. I DON'T advocate putting blinders on for the Top Down approach, either. Due diligence in surveying the full context of a process is always required.