BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, July 08 2014, 09:51 AM
  4.  Subscribe via email
In your experience, what are some of the biggest myths companies have about BPM?
Peter Franz Accepted Answer
BPM is a "silver bullet" technology?

Clearly the answer is in the "M" of BPM. It is a management discipline that should received the same level of focus and support as any other function (like HR and Finance). It requires the proper implementation of the process of process management with the appropriate strategy, governance and technology support. This is described in the patent pending BPM-D Framework that you can read more about at http://www.bpm-d.com/framework.

Now more than ever before Process Management is the answer to Strategy Execution - moving good ideas into action fast and with certainty. SO - NOT at silver bullet technology but an important differentiator for the next decade.
References
  1. http://www.bpm-d.com/framework
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Keith Swenson Accepted Answer
The biggest myth in BPM is the belief that there is exists one single best way to do something that is non-trivial. This assumption lies beneath everything in BPM. The belief that there exists a single best way drives people to try and identify the single best way. Then to try and get everyone in an organization to do it that way, even when the environment around the process and the circumstance are (nearly) infinitely varied.

Trivial tasks can be isolated and forced to be uniform, and the differences unimportant. For example, find the single best way to bolt a car seat into the body of a car, in an isolated factory, with parts designed specifically for the task. There exists a single best way for these routine tasks, but the mistake is thinking that the same technique of isolation, codification, and incremental improvement will work at the scale of tasks that actually important: such as closing a major sale, finding a cure for a disease, or negotiating a peace agreement.

It is as foolish as trying to find the single best shoe size, and then making every shoe that size. Even if you build in variation for foot size, imagine trying to find a single style of shoe that is best -- you will never find a shoe that is both a hiking boot and a ballet slipper. It is like trying to find the single best dinner recipe, and then making all restaurants prepare it in exactly the same way. It is the variation and creativity of the chef that makes us want to sample a number of different restaurants.

The attempt to find the single best process and to enforce that, is simultaneously an attempt to remove all creativity and innovation from the organization. You don't learn from success, you learn from failure. It is the variability and constant flux in the workplace that bring about an organization that learns to distinguish the right thing from the mistakes.

It can be quite disturbing to realize that the very core of BPM -- to isolate and optimize processes -- is at the same time the biggest myth when it comes to processes on a scale that matters.

Consequently, management gurus know this. Here is a post that explain how top management advisers do not insist that process uniformity is the goal of the organization: http://social-biz.org/2013/10/25/do-management-gurus-encourage-process-enforcement/
References
  1. http://social-biz.org/2013/10/25/do-management-gurus-encourage-process-enforcement/
Comment
Oh! And as long as we're near the subject I'd like to be very clear on one more thing in particular. That lady or gentleman in the cubicle who's been there twenty-five, thirty years? Who's worked in every department? Who knows the process(es) inside and out, both within the department or business unit and across business units and lines of business? That individual is worth their weight in gold. That person, if authorized and empowered, can do more process improvement, innovation damage in a few weeks or months than any amount of process modeling, analytics or a BPM guru, ninja, visionary, thought leader or death squad every time. Give me that person every time, yep, you bet.
  1. Patrick Lujan
  2. 2 years ago
Maybe, sometimes we do a task or process within a solution for a client based upon our knowledge of the toolset, the client, the industry, the solution, then we run it and metrics comes back and we decide there's an even better way to do it. Thus the "rinse, repeat." Best practices, "guardrails," re-usable assets - they're just a starting point. And how well they do depends upon how well we understand the process(es) and any variability there may be within it, them.

Most things that matter have a cost and most clients care about that much moreso than they do innovation. They care about doing it better, faster, easier, cheaper than the next guy.
  1. Patrick Lujan
  2. 2 years ago
So then, you believe that there is a *single best way* to do something for this given solution for this given client?

I agree with your point that it is widely acknowledged that different organizations will need a different process. I was not trying to say that. My point is that even withing a single organization, for a given process, people search for and attempt to identify, codify, and optimize the single best process for that organization. When applied to non-trivial work, this has the effect of eliminating all creativity and innovation. It only works on fields where there is no need for creativity. Most things that matter benefit from innovation.
  1. Keith Swenson
  2. 2 years ago
Huh? Best practice(s) are not equivalent with there only being one right way to do things. The issue with BPM is, has always been, what is the best way to do something for this given solution for this given client. The same task for another client, another solution, may not necessarily be done in the same manner.

To be more specific, re: best practices. Every platform, every technology out there does certain things, certain ways well. That is, they are all idiosyncratic, thus some are good widgets for this problem or solution, others not so much. Best practices are the empirical body of heuristics for a given tool or platform that build up over time - "do it this way on this platform for this particular problem because it does 'x' well." Problem is, without expertise, too many people interpret that construct as the way to do it every time. That's not a myth, that's just inexperience and or laziness. It's why we hear from (honest) vendors "it depends," which, yes, I know drives some people nuts, but that's just an exercise in drilling down deeper into the problem.

The "sensitive spot" is your hyperbole and exaggeration to engender the solicitation of your own particular flavor of Kool-Aid. I get enough of that from the top tier vendors. From the third tier ones it's... redonkulous.
  1. Patrick Lujan
  2. 2 years ago
Oh, I seem to have touched a sensitive spot. Explain the meaning of the term "best practice" if nobody, repeat nobody, believes that there is a best practice.
  1. Keith Swenson
  2. 2 years ago
Nobody, repeat NOBODY, with half a brain, any amount of common sense or intelligence believes that there exists one single best way to do something that is trivial, non-trivial or otherwise. That purported "myth" is equivalent to the Lewis Black joke talking about the cat getting run over and saying the cat was asking for it. We all have to agree on what we're saying and seeing both and this one... isn't.

Step away from the Kool-Aid, you have a purple mustache.
  1. Patrick Lujan
  2. 2 years ago
I actually second Keith's take. I have witnessed it many times, it's almost like a taylorist approach toward BPM, now mainly through its sexy cousin, process automation. No matter how we love to think that BPM is driven by people, when most of us look at the real implementation level, the project quickly takes on an efficiency approach, hence the natural propensity to seek a deterministic objective function (cost-saving, process speed) and its optimization variables.

@Patrick: there are a lot of half-brains involved in BPM... most of them are called clients, the rest of them are called process consultants. And the mere hint of a "best way" and a "best practice" is what makes process consultants sellable (and clients gullible).
  1. Bogdan Nafornita
  2. 2 years ago
I don’t agree with Keith.

The reality is that in any company or organization, automatic processes and procedures (computers, machines, installations, etc.) coexist with procedures where individuals play a major role, not only physical labor, but also their judgment when making evaluations, decisions and communicating with others.

The combination of these two ‘operating systems’ is present in all human activity. Even the human body functions, on the one hand with automatic processes that require no reasoning or decision (digestion, blood circulation, etc.), and on the other hand those where the mind makes judgment and decisions (to look for food, drink, comfort, relationships, etc.).

This coexistence is also present in BPM. Some processes, or activities within the processes, are perfectly defined and are sufficiently repetitive to make their automation appropriate; while in other activities, human intervention, with its creativity and decision-making, is necessary and essential.

A BPM suite should offer the necessary capabilities to combine these two scenarios.
  1. Mary Sempere
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Steve Weissman Accepted Answer
Two things:

1) That BPM is a technology. It's not; it's a business practice that can be ably enabled and supported by the proper set of technologies (plural).

2) That BPM means "You're fired!" First, that was BPR -- and second, BPR didn't mean that either.
Comment
Yeah, point #2 was a big thing c.1992. Point #1 is mostly just a discussion (argument?) we have amongst ourselves.
  1. Patrick Lujan
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Patrick Lujan Accepted Answer
Blog Writer
Contrary to many vendors and consultants both, it - BPM - is not a panacea that will solve all of an organization's process woes, much less fry up the bacon. Nor is any other technology for that matter. No grail here, just work, expertise and execution. Rinse, repeat.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Stephen Zisk Accepted Answer
Myth 1: BPM is an IT-driven initiative.

BPM is about making the business itself work better by using a process-based view of the business to understand, measure, and improve business interactions. Yes, it has to involve IT as a key player, owning the systems and applications that implement key parts of business processes. But fundamentally, the process "owner" is the business line or function that is responsible for the success of the process. And if it's a process that crosses business boundaries, as most of the really interesting (e.g. high-risk, high-value, complex, customer-facing) process are, then the whole leadership team is going to be involved.

Myth 2: BPM is a large-scale, high risk enterprise that takes a long time to pay back investments.

This myth often arises from a "boil the ocean" approach that assumes there is a single "train" leaving the station at a particular time, so you have to get everything and everyone on board. BPM *can* be a big deal, especially for late-adopters in fast-changing industries. But even if you know you have to make big changes, you still have to start small, gain experience, and use initial successes as investments (in employees, customers, and systems) toward larger goals. That also means you will need a BPM methodology and platform that support incremental, agile changes rather than a large waterfall project.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Peter Johnston Accepted Answer
People quite simply don’t understand BPM – it would be easier to write down what’s real!
But here's three persistent myths…

1. BPM is Methodology, not Software
In the golden age of business improvement there was one major flaw. No matter how clever the new process, it would decay over time. Managers would find a way of modifying it to their advantage, operators would find a way of avoiding the difficult bits and slowly, inexorably, the whole thing would begin to look nothing like the process originally designed, nor the process the company actually needed.

BPM as a methodology did improve on the process methodologies which went before it. But, like it or not, it is software which really makes that quantum leap. Why?

Suddenly you don’t have to find a single best way to do something. Cobble together any old process (or ideally let everyone collaborate on it) and let the data flow. In minutes you know exactly where the problems lie, where the delays are, where the resources aren’t optimal.

Then you can start working on improvements. After all, you’ve silenced the HIPPOS (HIghest Paid Person’s Opinion). You’ve probably shut your process improvement guru up on some things too. You can do split testing to see whether A really is better than B. You can back to back it with the old way of doing things. And you can see how people learn and extrapolate the graph to see where it might get to when they stop resisting it.

If you’ve done it right, by now you have people really seeing the difference. Hearing their feedback listened to and their ideas tried out. Everyone sees just how thorough a job you’ve done of really improving the process and making their user interface suit them. And if you’ve done it wrong – well you have the data to show why you want to do it your way.

Best of all, no-one can undermine the system. They have to fire it up in the morning and follow the instructions, hitting the submit button when they’re done – they can’t ignore the bits they don’t want to do, leave stuff in a pile or tweak the system to suit them. All the people who want to resist or undermine the change – well you’ve exposed their anti-company antics and stopped them in their tracks!

Did I say best of all? Well there is one more thing. Unlike other systems which decay in effectiveness over time as the process and the need for it diverge, the data is always there to keep it in line - it can evolve as the needs do. So instead of a constantly decaying process, you have a constantly improving one. As long as you don’t treat it as a guru driven project, that is!

2. BPM is an orchestration layer
BPM can be an orchestration layer. But only if you are too spineless to actually remove the legacy cr*p. BPM doesn’t need any of the layer it is supposed to orchestrate – it can do it all on its own. So have a clear-out of all your eighties and nineties “we run your business” software. That will give a bigger company performance improvement than even BPM can – and save enough in licence fees to buy you an Aston Martin! Remember that the day you accept legacy software is the day you hobble your company - putting saving a few pounds higher than being best or fastest you can be.

3. BPM is a Big IT Methodology
BPM is the ultimate in democratic software. Business people can design the process together. Anyone can see the data and follow the metrics to see a way to improve things. A better user interface or a process change is drag and drop in a sensible system, a datalink almost as easy. Continuous improvement through picking the biggest problem and constantly working to reduce it yields better results than complex waterfall methodologies. BPM is only hard because IT people want it to be.
Dynamic Process
Oxfordshire, UK
+44 (0) 1491 874368
+44 (0) 7590 677232
#dynamic_process
peter@dynamicprocess.uk
Comment
"BPM doesn’t need any of the layer it is supposed to orchestrate – it can do it all on its own"
That's a TALL order and starts to sound like a myth itself! Replace all the deep logic in ERP, CRM, SCM, ETC systems? I would opt for incremental improvement, extending and uniting the business logic into a flow that maps to the actual business flow. Maybe that is a myth itself?
  1. George Chast
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
My list of myths:

BPM is a business-driven initiative

BPM is an IT-driven initiative

BPM is a vendor-driven initiative

BPM is a consultant-driven initiative

One project is enough to implement BPM

BPM is part of SOA

“As all processes were documented, BPM is done – no need for BPM experts/group/COE anymore”

BPM is rigid (only one way to do something)

BPM is againts innovations and creativity

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Ian Gotts Accepted Answer
Ohhh. Where do I start?

Automation comes before Discovery

Adaptive Case Management is the answer

Companies are so agile that defining process is pointless

Systems are more important than adoption.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
David Chassels Accepted Answer
That BPM is a technology - it is not it is practice a way of thinking how best to achieve outcomes

That BPM has restrictions it should not nothing is off the agenda . The supporting technology needs to be understood before the journey starts
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Max J. Pucher Accepted Answer
Blog Writer
The biggest myth about BPM is its core selling point. The core of BPM's claim is that it single-handedly delivers the trifecta: lower cost, ensure quality, and increase revenue. It does nothing of the sort regardless whether you see it as a methodology, software or a combination of both.

BPM is not only a panacea, but also a religion and dogma and so many people's business and expert standing is centered on it that it won't go away soon, despite the simple FACT that after more than 20 years of BPM practice there are NO vendor independent studies that prove that it helps a business. I have even proposed mathematical models to show that a library of process variants has an incredible low probability to deliver the planned benefit even if 80% of them are correct. Not one response as to how that could be from the BPM community.

Keith is absolutely right that there are only a few processes within a business that can be improved through automation and most of those are already encoded into IT applications and or BPM software. Little need for a large scale BPM methodology.

If one takes the complete cost of the necessary bureaucracy to analyze, implement and then optimize these processes then it is quite obvious that BPM certainly does not lower cost (especially if it does not reduce manpower). BPM does not improve quality unless it is seen through a narrow SixSigma lens that only looks at how many processes have been delivered exactly as specified. BPM does not increase revenues because that requires processes that are mostly human collaboration in marketing, sales and after sales service and none of those can be automated.

People are intimidated by BPM these days. During my presentations I get 80-90% agreement from IT and business people on the need for a goal-oriented collaborative process approach. But the next sentence already says that the executives and their consultants have subscribed to BPM methodology becasue it promises predictability (Where there is none) and despite the lack of visible benefits there is little hope to make them accept alternatives. Bureaucracies both in government and business always work towards justifying an increase in bureaucracy. They never argue for a reduction of bureaucracy. It is so painfully obvious.

There is one thing that is not a myth and that is that most BPM experts think that everyone who does not subscribe to the BPM dogma does not only NOT GET IT, but he/she is obviously an idiot.
Comment
Max, "I understand."
  1. George Chast
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Bogdan Nafornita Accepted Answer
The core of BPM's claim is that it single-handedly delivers the trifecta: lower cost, ensure quality, and increase revenue.

The core of [insert methodology, software or technology]'s claim is that it single-handedly delivers the trifecta: lower cost, ensure quality, and increase revenue.

There, I fixed it for you :)

Other than that, yes, I disagree with you. (but still upvoted) :)

I will leave just one example off the top of my mind - growth hacking is proven to increase web start-up revenues when executed correctly. Correct execution means: formulation of growth hypotheses -> planning cohort size and timing --> coding (and the whole software development process required) --> A/B testing of hypotheses --> learning from outcome of A/B testing --> implementation of findings in final version of software.

Oops, looks like I just described a business process (and its management).
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Jason Noker Accepted Answer
to me the #1 myth is that BPM as a discipline is synonymous with BPM the software.

it's not.

most of the disagreements on this board are related to that fundamental misunderstanding. People referring to software and application development methodologies are not speaking the same language as those with a process, BPR, EA focus.

#1a myth is that BPM software can be implemented by non-technical 'analysts'

unfortunately most of the low-end vendors continue to perpetuate that myth.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
George Chast Accepted Answer
My gut reaction? The business OR IT myth. After Thinking about it? The myth is that BPM is different and warrants this discussion.

We keep discussing BPM as if it is something different from what exists already. In quite a few ways, it is something different. But, from another perspective, there is no difference between BPM today and apps from 20 years ago. Here's why: There exists no practical business model today that does not rely on information systems. Those systems support a portion of the business, more today than yesterday. With BPM "Discovery" one can look at the business processes across systems and gaps. Many process improvement teams do this today. BPM "Automation" fills the gaps by creating IT solutions in BPM that can choreograph other systems functionality (more so than apps themselves) and provide common UIs with task lists and dashboards. So can custom code. But, the two, Discovery and Automation do not always happen together. My assertion is that the myth is that BPM is different than IT in any form. It is just a later model with lots of improvements. No myth.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Mary Sempere Accepted Answer
That DCM (Dynamic Case Management) and BPMS are two different applications because BPMS is too inflexible to manage cases.

Most opinions on this topic are well-reasoned but, as BPMS is the software that manages the business processes in a company, and the Cases form part of the activities that take place in the company, their management should be present in the company’s BPM strategy and within the capabilities of the BPMS that supports this strategy.

If we state that BPMS and DCM are different things, then we should redefine the BPMS acronym as ‘Business Process Management Suite… excluding Case Management Processes’.

As this doesn’t make sense, the BPMS must be capable of controlling the DCM processes in all circumstances. Therefore, if a BPM suite is too inflexible and does not include the necessary capabilities to manage Cases, then that BPM suite is obviously just not up to scratch.
References
  1. http://www.auraportal.com
  2. http://www.auraportal.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Alisa Addison Accepted Answer

Myths about Business Process Management:




Only big companies should worry about business process management.

Process management is too complex.

Training staff on business process management will be time consuming.

The value added to my company by using business process management would be negligible.

BPM is only for complex processes and large businesses

BPM solutions are expensive
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.