Resolved
4 votes

I've always found 80/20 rules to be useful, so in your experience, how do you apply the 80/20 rule to BPM?

Thursday, May 21 2015, 09:47 AM
Share this post:
Responses (14)
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, May 21 2015, 09:56 AM - #Permalink
    Resolved
    9 votes

    80% of the results can be achieved with 20% of the BPM software product 'sfunctionality. Which is why this time around we are only going to develop the 20% that is really needed. So we were lucky that we can use the last company as great learning, albeit a successful exit. Actually we think it is 90/10

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 10:06 AM - #Permalink
    Resolved
    4 votes

    Only 20% of the processes might benefit from process methodologies from the 80's.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 10:46 AM - #Permalink
    Resolved
    8 votes

    We use 20% of the BPMN standard to design 80% of the required process functionalities...

    We spend 80% of our development time complementing the application logic with cron jobs, scheduled tasks and stored procedures because we don't understand even 20% of how boundary events are handled by BPMN...

    We spend 80% of our debug time clicking through 20% of the property panels of the graphical BPMN objects...

    We spend 80% of our process console analysis time trying to understand why 20% of our process tokens get stuck in a peasantly-designed error-treatment loop (see first para)...

    Like
    1
    • Patrick Lujan
      more than a month ago
      Awesome. Hilarious and sad both, but true nonetheless. 10 points to Griffendor.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 10:48 AM - #Permalink
    Resolved
    5 votes

    Normally, 20% of business processes are responsible for 80% of business activities, independently whether are being done manually or automated. A complementary rule is to choose the 20% of business processes depending of business strategy, e.g. if strategy is based on cost eficciency, we should choose the 20% that represents 80% of activity volume, but if strategy is based on innovation and quality, then we should priorize by processes that support Research&Development, Marketing, etc.. Thus, 20/80 is an important rule to approach BPM projects which allow to ensure positive business results more quickly without waste of time and costs.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 11:01 AM - #Permalink
    Resolved
    4 votes

    The example I always prefer about 80/20 is reporting. Every customer asks for several colorful reports.

    But the 80% of their real needs on reporting is covered with the some basic but powerful reports: volume and times (about 20%(?) of the potential reports)

    First: Volumes of processed process instances (create an instance, process and instance, reassign and instance).

    Second: Elapsed time, since the process instance creation until it is finished; and the time spent in each step of the process.

    Taking advantage of this Pareto principle, we included in INTEGRADOC a Business Intelligence module, already configured, that automatically measures these two dimensions from day one (when the product is installed). 

    The reply is currently minimized Show
  • Accepted Answer

    Maria Paz
    Maria Paz
    Offline
    Thursday, May 21 2015, 11:15 AM - #Permalink
    Resolved
    5 votes

    I agree with Ian Gotts: 80% of process management needs can be fulfilled with only 20% of BPMS functionalities.

    So the question is, why do companies have to pay for that extra 80% that most of the times isn't even used?

    Wouldn't it be much more useful to have a System designed to cover 80% of the needs and charge 20% of what other world class Systems charge?

    Only then would BPM be considered a necessary and smart investment.

    • E Scott Menter
      more than a month ago
      Except that I've noticed that the specific 20% varies from one organization to another.
    • Patrick Lujan
      more than a month ago
      "Wouldn't it be much more useful to have a System designed to cover 80% of the needs and charge 20% of what other world class Systems charge?" See Microsoft Office
    • Scott Francis
      more than a month ago
      Similarly, we pay for four to five seats in a car but 90% of the time we're only using one of them... why do we have to pay for the others? :)
    • Maria Paz
      more than a month ago
      I agree with both Scotts. That specific 20% does vary and isn't static. But there are some functionalities which are common for all organizations and those should be included no matter what.
      And you are right; we don't always pay what we use. But we do chose a car which meets our specific needs in order to avoid paying extra stuff that we don't need. We can't chose a car with only one seat (that wouldn't be a car), but we can chose the most luxurious one, the one best suited for families, etc. Plus, a car isn't a good example since it can't be adapted. Software can and it should. A good solution (and very common nowadays) would be to include free or affordable features and then add premium ones for organizations to choose if they really need them.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 12:17 PM - #Permalink
    Resolved
    6 votes

    80% of the responses in this forum could be expressed in about 20% of the actual number of words used. :)

    Aside from that... I tend to agree that a given organization uses about 20% of the overall feature set of a BPM solution such as Process Director, which itself is considered a "lightweight" platform. But I'd also point out that when customers are comparing products prior to purchase, they tend to build a shopping list which calls for a number of features far larger than the set they will ever actually use. Analysts are partially to blame ("look for a solution with adaptive activators and elevated sensor integration"), but to be fair, it can be awfully difficult to know in advance what you're going to need with a high degree of accuracy.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, May 21 2015, 12:51 PM - #Permalink
    Resolved
    4 votes

    This is from a paper I wrote titled, "When You Hit a Wall, Go Around It," I wrote back in 2004 (the link is below). Here is how I see the 80/20 rule applied in systems:

    Years ago we were hired by a Blue Cross/Blue Shield plan to look over a new Claims Processing system they were building. The focal point of their problems centered on adjudicating claims whereby they wanted to devise an automated way to analyze a claim and determine the amount of money to be paid out. They had spent a lot of time and money analyzing adjudication and were frustrated they couldn't come up with a standard algorithm for computing all claims. We studied the problem and found that 90% of their claims were easy to analyze and calculate adjudication. For example, simple doctor visits, a broken bone, normal childbirths, etc. were easy to analyze and compute. However, unusual medical claims such as complications at childbirth, and accidents from a massive car accident, involved many more variables and, consequently, were difficult to compute based on standard algorithms. After studying the problem carefully, we reached the conclusion that trying to accurately calculate 100% of all claims was an impossibility. It was simply not practical to try to achieve this lofty goal and, as such, was a waste of time pursuing it. Instead, it was our advice they simply automate the 90% claims they could easily perform and segregate the remaining 10% for handling by a human adjustor. To their surprise, this worked remarkably well and saved them considerable money.
     
    Too often in systems and software development we try to do the impossible and often run into a stumbling block when trying to achieve our goal. Do we continue to waste time and money on a problem that cannot be conquered or do we stop, lick our wounds, and move around? The problem is knowing when to stop. As "Dirty Harry" once said, "A man has got to know his limitations."
     
    Let me give you another example. Years ago, we devised our own set of in-house programming standards. These standards were used in Phase 4-II of "PRIDE"-ISEM and allowed us to engineer and review a program before coding. We then took it another step by creating software that would read the program's specifications and generate the initial source code. We called it a "Program Shell Generator" for it generated the lion's share of the code (be it COBOL, C, or any other language). It could generate 100% of the code for simple programs, but we recognized from the outset it couldn't do everything. Instead, it would generate approximately 80% of the code which the programmer would then have to complete. Some would say such a generator would be a colossal waste of time. Far from it, we found it to be a tremendous time saver. Instead of wasting time setting up the initial code, the programmer was free to concentrate on the 20% of the code requiring their attention. Other program generators are faced with the same reality; they can generate a lot of code, but probably not 100% for any major application of any substance.
     
    It is important that Project Managers and senior analysts be wary of such potential roadblocks and not try to conquer the impossible. Instead, look for practical solutions. In other words, don't try to drive into a wall, turn on your turn signals and go around it.
     
    Copyright
    • Patrick Lujan
      more than a month ago
      Interesting. I find your examples and advice analogous to documentation in Agile - "only to the necessary degree of understanding." In a like manner, for process, "only to the point of diminishing return."

      Practicality, there's a concept.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, May 21 2015, 02:00 PM - #Permalink
    Resolved
    2 votes
    For those interested, here is the precise meaning of...
     
    80/20 Rule (ak "Pareto’s Principle")
     
    I have often been asked why it seems only a handful of people always carry the workload. This is not uncommon and is found in everyday life as well. It is commonly referred to as the “80/20 Rule” or “Pareto’s Principle.” Vilfredo Pareto was an Italian economist who observed in 1897 that 80 percent of the land in England was owned by 20 percent of the population. Pareto’s theory thereby relates to the ratio of input to output; e.g. twenty percent of your effort produces 80 percent of your results. From a time management perspective, it means 20 percent of the people are normally responsible for producing 80 percent of the work.
     
    As a manager it thereby becomes important to recognize your core 20 percent workers and concentrate your attention on them. It also becomes important to devise new means to squeeze out the remaining 20 percent of the work from the 80 percent who do not actively participate. This is not to suggest the 80 percent do not care about their work, they just may not be as talented, experienced or as motivated as your 20 percent workers.
     
    One dangerous byproduct of the 80/20 Rule is petty jealousy. Since the 20 percent performs the work, they are thereby deserving of the accolades for performing it. Inevitably, it is not uncommon for small minded individuals from the 80 percent group to feel slighted and jealous of those doing the work and receiving the recognition. Such petty jealously should be overlooked and the person forgiven, unless something more malicious is involved, such as character assassination of which there is no excuse. The manager must carefully squash this behavior before it has an adverse effect on your 20 percent. If not, the 20 percent worker will question why he is working so hard if he is only going to be the object of ridicule and humiliation. The 80/20 Rule is an interesting phenomenon every manager must be cognizant of to get the most out of their workers.
     

    References:

    1. http://timbryce.com/
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 21 2015, 02:39 PM - #Permalink
    Resolved
    6 votes

    Its an audience thing: When I ask a specialist they want 80% gadgets to basically achieve 20% what's really needed by the business... And as BPM has been glued to technology the last 20 years, you'd therefore often end up with nuclear missiles to kill a mosquito...

    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 22 2015, 04:45 AM - #Permalink
    Resolved
    4 votes

    80 % of BPM community confirmed that only 20% of BPM potentials are delivered so far.

    80 % of BPM problems can be solved by 20 % of architecture.

    80 % of all business processes can be constructed from about 20 business patterns.

    Thanks,
    AS

    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 22 2015, 10:50 AM - #Permalink
    Resolved
    4 votes

    80% of statistics are made up, 20% are based on actual facts.

    If you took only the 20% that is used, you would still find the 80/20 rule applying to that remaining 20%. The distribution curve doesn't change just because you clipped the bottom of it.

    I can bemoan paying for the extra seats in my car, when I typically only use one of them... but when I need those other seats it is pretty handy isn't it?

    When products add functionality (complexity) the developers/designers need to think about how to hide that complexity or only bring it forth when required, rather than all the time.

    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 22 2015, 12:48 PM - #Permalink
    Resolved
    3 votes

    SELLING BPM SOFTWARE ON PREM OR IN CLOUD

    1. Against alternatives such as coding + frameworks or legacy workflow or (formerly) application generators or even ERP native functionality . . .

    2. you can say "X is really good at getting you 80% of the way to where you want to go, but for the last mile, you'll need more power . . . "

    3. and add "what do you think it's the last mile where you build real winning business value? The 80% is the easy part, it's the commodity part of what you do. But the last mile is where you define the unique semantics and ways of doing business that earn you your margins. Do you want to go beyond a level playing field with the competition? Let's explore how this is possible . . . "

    4. So the approach isn't being negative about alternatives, rather highlighting the opportunity to move forward, courtesy of the 80/20 rule.

    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 22 2015, 09:27 PM - #Permalink
    Resolved
    2 votes

    20% of Business Process are responsable to delivery 80% of organization's results and may impact the value for Customer.{rokcomments}

    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
275 Replies
23/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
24/09/2016
E Scott Menter
182 Replies
23/09/2016