BPM has a tarnished brand and reputation. It has had 30 or more years of valuable, yet under-estimated work. It has been misundertood (IT product) and mis-represented (reasons to sack people). Can it be improved or does it need to completely reinvent itself? My view is thre is too much baggage associated with BPM. It will continue to improve and the analysts say it is growing at 8-12% per year. But to really make a difference a complete rebrand may be required.
I'm going to come at it from the other view. Not outside looking in, but inside looking out. Tarnished brands and reputation are a consequence of poor communications, poor expectations or understanding, poor execution.
On the ground, in the trenches, it's expertise. Always. On the business side - What do we want to do? What do want to accomplish? - and on the technical side - How do we do, what's the best way to do that? - both.
Crap reputation is a consequence of crap execution.
It's the supporting software that has historically failed BPM; nothing wrong with the discipline which has been around for many decades. Maybe too easy for consultants to sell their words but they have failed to really understand the required software to actually deliver the digital solution.
Suggest much more effort needed to understand "how" the software actually works to deliver on required outcomes not just rely on vendor hype. The other issue is such software should not be called BPM needs to have a tag that describes its capabilities? My vote goes for "Adaptive" a movement that has already set some good requirements and user focused.
I think that BPM has currently enough technical solutions to be supported, both in management and operational level.
In my opinion, what needs to be improved is market approach, in terms that customers understand what is the real added value that BPM can bring to their companies. From my own experience, the operational level it's easier to understand by IT people (normally involved in these decisions), while the management level is hard to understand by business people. Paradoxically, the BPMS solutions are just focused on technical implementations, not to measure the business benefits, and this is the point that needs to be improved toward to business people.
Management techniques that help them to understand clearly how it's possible get benefits, using the BPM for business transformation, can be the key of improvement, and as well good communication of business cases.
A while back I wrote a blog supported by an amusing, but very poignant video called "process discrimination" The thrust was that you say that you are involved in process and you are immediuately discriminated against. Replace process with BPM and you have the issue here.
As Ian says above, BPM has been laregly misrepresented and/or misunderstood. Let me share one story.I've been around BPM for now 10 years, always from the vendor side but having interacted with many customers to define strategy, gather requirements, and implement solutions. Three years ago a couple of Lean Six Sigma Master Black Belts joined the company. They felt, and for good reason, expert in BPM, but when I spoke to them about BPM I felt that I was speaking English and they Chinese. Our experience tackling BPM, or in larger sense business transformation, required a good 6 months to synthesize into a common approach whereby we, the LSS and BPM communities, now understood how to harness LSS tools (e.g., DMAIC, Value Stream Maps, SIPOC, Process Charters) to fully leverage BPM suite features and functionality to better guide Business Analysts and Developers while gathering requirements to fully realize the fruits of automation (reduced costs, improved quality, faster service). Apply this to the BPM market space. So many people are coming into BPM hearing/knowing one side of the story, when real success requires both reading and knowing the whole book. That is why product is just one element of BPM. People, product, and methodology must come together to be successful. I've started preaching this to all customers and partners. You can buy a BPM tool, learn it, and have some success with it. But you can fail just as often. Real success comes from combining good methodology with smart, qualified people with the backing of stakeholders to effectively make changes using the right tools. For enterprise-class BPM projects, people can become the main impediments. Lack of knowledge of product capability combined with lack of guts to battle against bad/unrealistic requirements and scope screep result in delays and unrealized beneifts. The BPM community - vendors, system integrators, analysts - need to continue collaborating to ensrue that customers get the right education, trainining, and support to cover all chapters of the BPM Book of Success to be truly successful.
UI/UX. BPM can already do so much, but those amazing capabilities are too often cloaked in a user experience that can best be described as unapologetically utilitarian. As an increasing number of customer-facing BPM apps are deployed, there is increasing pressure to transform the user interface aesthetic from "Soviet-era East German apartment block" to something more like "Sydney Opera House".
I wrote a piece on Quora recently which proved to be the most popular thing I've written there.
In it I described how, in the first phase of computing, big aggressive hard-sell companies were created along the "pushing tin" model.
How, when hardware commoditised, they moved into software, buying up any company that produced anything and branding them as theirs.
And how, now that enterprise software is also over the hill, they are moving on to Big Data and Internet of Things.
The problem for BPM is that it was a casualty of that in-between stage. Some companies created it to really make a difference. It did.
Then they got bought up by the big boys. Sometimes only really because it threatened what they were already selling - they wanted it so they could shut it down (isn't that right, Oracle). In other companies it was a tier two product - not really pushed by their top salespeople but seen as a niche product for finance (isn't that right, IBM).
So BPM has never really had the clout to prove what it could do. Giving it that push would be change one.
What made BPM special was that it took Lean and Six Sigma and added software.
For years Change Practitioners had struggled with implementation. People would take their recommendations and change them subtly to suit themselves. Or wait until the project team had gone, then either gently undermine the bits they didn't buy into, or simply change things because they didn't realise how they were interconnected. The result was that effectiveness decayed over time.
Software changed all that. Suddenly the software was the system - and it was easier to follow the system than to change it. So the system stayed as good as the day it was installed - the only decay was that the business needs would move on.
But the project methodology meant that we missed a trick. The software produced oodles of data. Really powerful data for turning the sytem from 50% effective on first iteration to 90% or more. And which gave an early warning of changes in market need. The potential is there to make machine learning sytems which, rather than decaying, improve with time as the data gets better and better.
This requires a different approach. Instead of the project, the waterfall, the "create and impose"; BPM is at its best done as a continual optimisation process. It can take the six sigma - take the biggest problem and halve it - thinking to its extreme.
So why don't we do it? Because of those self-same BiG IT company methodologies, focused on the single sale, not the SaaS model of continual feedback of the data and remote improvement of the system which BPM could, if it tried, lend itself to.
So the biggest change? Make BPM something you can remotely change - and regularly do, driven by the data. A continually evolving, self-optimising, market need aware, process which suits the company's needs now, not the ones which were front of mind when the project team happened by a few years back.
I strongly agree with Garth. In fact, I usually use a slide in my classes asking the students,
What are the key points in a successful BPM Implementation?
And the right answer would be:
3) People !!
In sum, I find nothing wrong in BPM, I don’t believe it has to be reborn. As any other discipline is has evolved, adapting itself to customers’ needs. And it will continue evolving until not being a separate discipline or technology, but part of the stack.
Reading and agreeing with most above comments, I think what happened to BPM, is what it wants to prevent in organizations: Big walls between all parts that should work together
And BPM has many parts, because managing processes is daily business. And to execute and manage a process (or actually, cases) you need a lot of things:
- a way of working (wokflow)
-supporting stuff like tooling
- proper way of managing
- etc, etc
So where does BPM needs to be improved? I think in the BPM community itself. I experience a lot of times big misunderstandings between the cool guys of the software, the losers of the methodology, the stick-in-the-pasters of six sigma and the marketing-experts of big analyst firms.
So as the goal of BPM is to let people work together towards a useful result, it seems that the BPM community itself has a hard time doing that.
But....what is the BPM community?
I agree with Patrick on "the poor reputation" as a result of "crap execution". I think the vendors can help a lot more here, byproviding more out of the box features, particularly frameworks that give business and System Integrators more of leg up when starting a delivery. Some vendors like Pega systems are taking this one step further than frameworks and moving to vertical applications. I think this is a good move and will really help customers to not only accelerate delivery but also more likely to get some thing that works out of the box. I've used frameworks from other vendors and these are invaluable when scoping and desiging an project.
- extend the scope of the BPMN notation - include DATA and CASE. I have a special grudge with data. How is it possible that we declare data modelling as out of scope for the BPMN and still wonder why the hell isn't BPMN picking up in adoption? Who in their right mind do BPM without data? Let's face it - the current BPMN incarnation is an incomplete solution to any business problem. That's why we have all this cacophony of tools and partially supported specs. And then whine about slow BPM adoption.
Solving business problems only with BPMN is like trying to make cake using only flour. ("Oh - the sugar is out of scope!")
- unify the communication and the execution purposes of BPMN by having layered views (strategic / business / modelling / technical) on top of the same model. Business people don't need the technical details but everybody should work on the same model. The model will become like a picture where you could zoom to your own desired magnification (and resolution) to get the right info for you.
- as said above, this will be achieved faster by delivering vertical applications (DSL anyone?), as the solution becomes more palatable to customers.
The rest is just generic stuff, like having the right people, the right method, the right tools, the right budget etc
I'm with Ian (and not only because he used to be my boss :-) ). And when I go through most reactions I think most are on the same or at least similar page here.
Next month I will publish an article in Computable (one of the Dutch specialised papers for IT technology) that addresses exactly the same question. Currently translating it into English. Summarized the article positions especially the letter "M" which IMO has suffered the most (and not only in this three letter acronym by the way). Reason I don't publish it in magazines where you would expect this view (BPM as a management discipline :-)) is obvious: You would only get a loud murmur of assent.
So... Going on with trying putting BPM back to "where it belongs" might be pretty useless, an academical discussion say, but certainly a waste to spend a lot of time on. The way I threrefore nowadays go with this is simple: I use the acronym and immediately add the definition in order to be very clear about the proposition. And yes, perhaps we need to rebrand (which of course is the sad thing, as in the end the only thing you want is to improve the way how you get positive business results in all aspects).
I agree with Bogdan regarding the missing domain and systems view.
Absent data and integration leads to an incomplete narrative. Though the unfinished model is overly simplified and therefore easily understood, the missing details typically leads to a patch-work implementation with little to no planning for operations and support (no systems view = no systems).
Same goes for critical feedback loops (i.e. archetypes) and various other non-standard features.
Would be nice for our BPM standard(s) to include something more than extension hooks - maybe something concrete (or examples thereof) pointing at the more ubiquitous forms of domain definition, integration models, and technologies.
Our open-source vendors look to be heading this way by the nature of their execution/runtime platform. But what should be a common standard then becomes a division of methodology and patterns.