We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

Top-down or bottom-up: what works best for a BPM installation?

Vote 1 Vote
Top-down or bottom-up: what works best for a BPM installation?

12 Replies

| Add a Reply
  • Initially, for analysing the problem, Top-Down. For customisation of the BPMS installation, Bottom-Up.
    As such the answer is both. And they have to meet in the middle.

  • An analogy I wrote on this very subject in 2009...

    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, 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”, 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 or operating model."

    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.

    The puzzle analogy is a pretty good description of the difficulty we face in BPM. The puzzle pieces are process information and data that an organisation has been collecting for years. Each month, new statistical information, data or process is collected and analysed, creating additional puzzle pieces. Sometimes the data collected will contradict the data from another source, and because it can be interpreted in different ways there will always be disagreement.


    Without the inclusion of a “top down” framework, there is no consensus on what pieces to look for, which pieces are more important, or how to interpret the overall solution.

    So I agree with Adrian, it's a bit of both, but for different reasons.

  • Both as per Adrian's response. And I do them simultaneously as BPM solutions and BPMS platform's deployment usually give each other context. That is, these efforts are a discovery process into the organization itself and so you need the macro and the micro views. The process model(s) as you're drilling down from 20,000' to 200' inevitably make themselves known and that, in turn, iterative and incremental here, helps you build those tactical solutions that build out to that strategic end-state.

    Most people run out of attention (discipline) and gas (funding) both before you get there though.

  • Agree with my esteemed colleagues. If you want something of enduring enterprise value it necessarily must be 'both'.

    Top-Down is one way to look at things, but a better label might be 'system-wide', it's critical to account for cross-cutting concerns (master data, governance, value chain integration, etc.). A 'bottom-up' or 'outside-in' approach is parochial by design, lacks system-wide perspective, it leads to process silos that make future integration more difficult.

    The key is to balance gratuitous central control (bureaucrat w/o a clue) vs renegade business unit (rebel w/o a cause).

    That's why adaptivity / interoperability are the major concerns of the day. If your process technology doesn't support these - it's time to look elsewhere.

  • I agree with the answer 'both'.

    The choice to manage your organization by process is what some people call strategical. That seems quite top down to me.

    I see this top down initiative as some kind of guide for the (bpm) trip an organization will make. But a guide alone is just a guide, so bottom up we need people to walk.

    If there is no guide people will walk but where to? If there is a shouting guide that cannot explain where we go, people refuse to walk.

    So indeed both are needed to get somewhere.

    But in the end every company is already doing BPM (they are walking) but the guide is needed to walk the right way.

    • mmm, I see now I'm not talking BPMS

      In that case it must just be installed top down by the IT department (supported by expensive consultants) and after that end-users pretend they use it ;-)


  • Theo is right, it is a puzzle. In addition it is a balancing act taking into consideration business maturity, financial and market dynamics.

    Theorectically, you start top down as you have to understand business objectives and understand key capabilities to achieve the business strategy. With this you build the processes that can plug and play into delivery + support of the business to consumers (or businesses).

    But the reality, is that businesses are all over the map with their value propositions, internal process maturities, what the market is doing or forcing on the business, financial pressures etc.... Thus can't always afford top down or to wait for top down to be done. Putting aside those organizations that have built top down and have the stratgic roadmap, we know not everybody has the luxury of starting with top down nor the luxury of time so the focus shifts to tactical problems thus bottom up begins.

    One side note that is interesting from a bottom up approach is the innovation factor. Sometimes fixing a local and tactical problem reveals a new and innovative way for the business as a whole.

    The success I have seen is where organizations take parallel paths, ie. top down and bottom up, and learn how to bring them together at certain points to measure, align/deploy, and recalibrate. As Dave says, adaptivity/interoperability are major concerns of today and I would argue that is the real nut to crack. Putting a puzzle together requires trying different pieces, being flexible and willing to put a piece aside to find another more appropriate piece. There are different areas of the puzzle that will come together sooner than other parts. An organization that has the ability to learn and adapt at several levels will move the whole BPM transformation forward.

  • Seems to be agreement both. My slant from our experience with our Object Model Driven Engineeing tool is top down by the brave businessman that takes on IT and the bottom up who are relieved IT are not involved!

  • My response to this question ended up as a blog post:

    http://www.ebizq.net/blogs/bpm_view/2012/10/bottoms-up.php

    I'm not entirely comfortable with the various analogies offered above. The truth is that BPM is too valuable as a rapid solution deployment platform to weigh it down with the baggage associated with top-down corporate initiatives. And with the advent of cloud-based BPM, ROI is faster and easier to achieve than ever.

  • Bottom up has always proved more successful in our experience. Start small, think big. 80% of an organization's processes are fairly simple in nature—the impetus being a request from an end-user—User A needs this, the request needs to go to User B for approval, and once it's approved it's sent to User C to fulfill. Getting bogged down with the other more complex 20% with a top down approach results in nothing getting done any time soon. Bottom up with smaller department wins allows for users to get used to a system, provide feedback, leverage best practices and make improvements before moving enterprise wide. Not to mention providing some immediate ROI.

  • While BOTH is the better answer than one or the other, it actually considers only part of the story. What about 'Outside-In' which is pushed by a whole community as an effort to focus on customer interactions or touchpoints? To make it even more confusing I would add 'Inside-Out' which can be understood as looking at it from a business management perspective. Can we ignore that?

    You basically know what is coming, right? We actually need all of them. We also need to 'Think Big and Act Small' as I wrote in a recent blog post: http://isismjpucher.wordpress.com/2012/08/27/bpm-vs-bpms-how-to-think-big-and-act-small/

    One can consider it a puzzle and in many ways it is but it is really not 'puzzling' if you approach it the right way. So we approach it from ALL SIDES at all times? In principle that is correct, but the best term to describe it is BUSINESS TRANSPARENCY. What are the concepts that define the processes to be executed?

    Top-down: business objectives, value streams
    Inside-out: operational targets and process goals
    Outside-In: customer perception and experience
    Bottom-Up: people knowledge and innovation

    You will notice that there aren't any orthodox BPMS that support any of these explicit definitions or allows the monitoring of such concepts. The only place these things could be considered is within the governance organization, but you know that they aren't.

    Russel Ackoff:
    "Because most managers don’t have the knowledge and under- standing required to deal with complexity, they attempt to reduce complex situations to simple ones. As a result, they tend to look for simple, if not simple-minded, solutions to problems. For this reason managers are susceptible to management gurus pitching panaceas. In my experience the larger consulting firms are the most guilty of promulgating fantasies like benchmarking and process re-engineering."

    So pardon me for sounding jaded, but there is no simple answer for bottom-up versus top-down.

    BTW, 80% of a companies processes aren't simple! Where is the study to proof that claim? Real world projects show that maybe 20% can be done with flows and the rest is too complex. 80% of the processes being done are maybe simple. BPMS are being used as programming tools that have nothing to do with managing business processes.

  • Theo's analogy is a great one, the only thing I would add is:

    Top down to gain an overview of the operation, structure and processes. Follow this with bottom up to understand how operations currently happen and then a mixture of bottom up with top down to understand perspectives on how operations should happen.

    All along the way progress using your expertise to translate between the lines and ensure you exceed objectives while providing future analysis that will give additional real return on investment financially and motivationally.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT