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
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)...
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 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).
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.
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.
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:
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.
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.