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

How big is a process?

Vote 0 Votes
From Connie Moore's Forrester blog, Tackle the Most Common BPM Challenges, she states, one person's set of activities is another person's process.  So how big should a process be?

16 Replies

| Add a Reply
  • How long is a piece of string ?

    How many BPM experts does it take to change a light bulb more like.

    I rest my case.

  • There is just one process. It is the end to end value chain of the business... everything else is a breakdown of that.

    If you have processes that are not part of and aligned to the top level process, then why to they exist?

    Unless of course they are part of the 'support' processes like Manage HR, Manage IT, Manage Facilities.

    So no you have the 2 ends of Theo's piece of string. Anyone for some knitting?

  • A very good question indeed.

    The importance of what BPM CBOK calls "Enterprise BPM" - processes mapping to overall value chain - cannot be overestimated. It's literally the matter of life or death for BPM because there are very little chances to do anything visible from company's bottomline perspective if such vision wasn't developed and the gap analysys wasn't made *before* BPM project launch.

    Another point about process boundaries: I used to believe that process improvement is about finding non-optimal parts of a process and redesigning them one after one. But after years in the field I found out that it's more about pushing the boundaries of the process.

    As an example, Tetrapack has changed the definition of their core process some time ago: now they consider the process completed not when a production line is assembled at the customer's site (Tetrapack sells these lines) but when it begins actual production. I guess their contractual obligations don't require this yet they know typical pitfalls that may lead to delays between assembling and production start so they are able to assist the customer. Removing these delays is good for customers hence it's good for Tetrapack so they decided to measure the process performance by the production start date.

  • As every good geek knows the ultimate answer is 42.

    Kidding aside - the first question is what does it mean to measure a process (time elapsed, number of steps, number of people\systems involved)? In BPMese the number of discrete steps (or as a proxy the number of nodes in a BPMN graph) is what I would guess most people would think defines the size of a process.

    I agree with Connie - a process should be just big enough to bring value to some constituency. Larger process grow by stringing together those as subprocesses.

    Ot how about this - a process should be no larger than what can be handled by checklist of 7+/-2 items.

    Jacob Ukelson - CTO ActionBase

  • Like asking "how big is a company?" Large companies are 5 orders of magnitude bigger than small companies. Processes are kind of the same, and they nest like those Russian dolls.

    I usually think of these four major steps in magnitude:

    Accomplishment: one or a few actions done by one person, lasting from minutes to days.

    Initiative: one or a couple of people involved, lasting days to weeks. Generally has multiple accomplishments.

    Project: several to many people involved, from a couple tasks to hundreds of tasks, lasting from a week to many months. Generally contains a number of Initiatives.

    Program: A collection of projects, any number of people, duration is very long, often many years.

    The kinds of things you need to do at each of these levels is kind of similar, but also varies across the range. The communications needs also vary: the accomplish may need very little communications, the initiative flexible, the project more organized, and the program level needs strong analytics and statistics.

    Processes fit in at any of these levels, when you have a set of actions that can be predicted.

    It is interesting to note that these levels of hierarchy are related purely to our ability to organize people. Some military organization have up to 7 distinct levels of hierarchy, and my guess is that they would be able to identify 7 different magnitudes of process.


  • A process is basically an input, some sort of action and an output. It can be as small as one person and one action or can be very complex with many different actions based on very specific conditions and could include very large groups of people. The important point is really to have a clearly defined well understood process with effective measures in place, regardless of size.

    • Tom

      From formal perspective you are right.

      But if I got the original Connie's post right the implicit question was "how big the process scope should be for BPM to be successful in the organization?" Do you mean the answer to this question is "any size"?

  • To me, "the end to end value chain of the business" is exactly the "breakdown of that"(process).

  • I've seen a process with 2 activities, no forms, no integration. I've seen a process with 200 activities, 20 different forms, and several integrations.

    The question should be what is the process you're looking to automate?

  • I think you are forgetting some important points.

    One is scope definition. The scoping contributes to the length of the process (process team can keep it short or very big). But scope definition can lead to contradictory results as explained bellow.

    Now the most important thing to realize when the process actually begins and when it ends.

    To this propose I will borrow an example from a colleague.

    The process is Open a bank account. This kind of account have a card included.

    The process starts when the customer wants to open the account (does not matter the channel used - internet, bank branch).

    Now the tricky part. When this process ends (pick one)?

    1 - When all the paperwork is signed and the bank informs the customer it's account number.

    2 - 1 + the customer makes an deposit and the money becomes available.

    3 - 1+2 and the customer can make operations.

    4 - 1+2+3 and the customer can use the card, for example to withdraw money?

    My answer is number 4, because is the ultimate output.

  • I would not concentrate on the size of a process, because a process does exist, but implicitly, and end-to-end value-chains is the answer. I would consider the actual question as which _parts_ of implicit process should be made explicit/executable via BPM and thus improved to justify BPM. For example, if there are performance problems at the beginning and at the end of client’s value-chain then building an explicit overarching end-to-end process may not be pragmatic.

    It should be easy to apply BPM to any part of existing value-chains. Find a “wrong? part (or, a point of most leverage), BPM it (explicit + executable + measurable + controllable), improved it, and look for next “wrong? part. Of course, a good architecture (proper modelling, ability to refactor, big picture in mind, reusability, etc.) should guarantee that those “explicited? parts will match each other’s (like a puzzle). – An illustration is available at http://improving-bpm-systems.blogspot.com/2011/02/illustration-to-ebizqnet-how-big-is.html


  • I think we all agree that there is not a unique response to the question.
    The point is not "how big is a process", the point is "how many processes of this size do we have" and "do we have the right methods and tools for those sizes"?
    As Phil Gilbert pointed out at BPM2010 (http://vimeo.com/15680641), a large share of processes (75% or more) are fairly simple and short.
    Is the "one tool fits all" paradigm good anyway?
    I don't think so, and current trends are showing this (think to IBM Blueworks Live and this class of approaches for instance): for small/simple processes you need much simpler tools. It's just much more productive.

  • It all depends on your approach...

    One process could be "massive", yet it is actually made up of many many many other processes, how big are those...

    This is one of those pointless questions as there is simply no right or wrong answer, as theo said, how long is a piece of string...

  • I wrote and posted this yesterday BUT the manual process (me) did not check the END point was complete! :);

    I think a process is only as long as a known trackable START point to a known trackable END point with no loss of control (or no lack of visibility as to the status) of the process in between.

    What people consider to be a "process", say a mortgage application, is often 4 or 5 processes where in between, there are manual steps (someone sitting at their computer doing a credit score on a 3rd party application). Here you've lost control. You know there's a process going on but this person may have gone to lunch or sent an email to clarify the SSN.

    Here at OpenSpan (sorry plug), we can extend applications running on the desktop (3rd party, SAAS, legacy etc.,) to the BPM engine and keep the now SINGLE process in the loop. We can even tell the BPM engine, the PC has logged off, timed out or even if the application is in use for the originator applicant of the mortgage.

    When built, all of these desktop applications were designed to assume that no-one cared about a transaction being in mid-process.

    At the very least, you need to be including ALL of the manual desktop interactions as part of the BPM now in 2011.

  • "Size does matter"

    Our experience to automate the health insurance enrollment process from application submission to cards delivery cost us so much that while there are benefits of transparency, compliance and maybe even performance, the return on investment may come about a time when the whole technological environment steps up to Generation Z!

    I advocate that the end-to-end is subject to the objective of the process. When a Product executive receives an RFP from the Sales guy to price it, his process could start there and could end when he gives the prices to the sales guy. The Product executive's objective met.

    I prefer small processes, manageable and possibly even modifiable without causing a major impact elsewhere.

    There is a saying in Malayalam, a language from Kerala, India, "Peck only that your Beak can hold". Hence, depending on your organization and your culture and capability, judge the "size" of your process.

    Connie was right, "One person’s set of activities is another person’s process."


Add a Reply

Recently Commented On

Monthly Archives