1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, July 15 2014, 09:49 AM
  4.  Subscribe via email
As Mike Gammage writes here:
Right now, adoption is the hidden problem. People put a lot of time and energy into working collaboratively with the stakeholders to build great processes. They link them with documents and metrics and systems. They wrap it all within a governance framework and launch it. Everyone is delighted. But come back a year later and it is, too often, in a slow decline.
So in your experience, what is the key to adoption for BPM?
Guest Accepted Answer

The quote says it all. BPM being that heavy is the issue. It needs to be super light weight.

Metrics, systems, governance frameworks all scare the end users. They are not against it, but the amount of work it takes to get them all in place is huge. We end up in operation success, patient dead situation.

Are you familiar with the share point effect? :)
  1. Scott Francis
  2. 3 years ago
Scott: can you elaborate?
  1. Michal Rykiert
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Antoine THOMAS Accepted Answer
Think end user first:
- document your process with end-users
- write the spec with end-users
- design the forms with end-users
- validate the proof of concept with end-users
- create a way for end-users to reports issues and propose process improvement over time

Of course, you can not always work with all end-users:
- some don't want to work on coming changes,
- some are not skilled enough,
- in big companies, there are too many end-users.

The best way is to ask team managers to select one or two "power users", or to ask interested people to apply to the "New Information System Design", or something like that
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Stephen Zisk Accepted Answer
The key to long-term BPM success is momentum. In physics, momentum is the product of mass and velocity. For BPM this means value and change.So in BPM, Success [momentum] = Value [mass] * Change [velocity].

Too often, we pick a "textbook" process like HR that may not be part of the organization's core value. We should instead pick a "weighty" project, like on-boarding, customer service, or product design and production. These may take more work to define, enlist support, and build, but they have the most potential to produce visible and relevant results.

Even more important is change. I still remember the story several years ago of one bank's award-winning BPM story. During the award ceremony itself, the BPM "expert" responded to a question by admitting a Six Sigma team had come in and changed the desired process, and, since the vendor's software was not set up for change, the BPM process became "shelfware"! If your BPM initiative (both methodology and software) is not designed from the start for incremental and ongoing change, you will lose momentum and with it, success.
your second paragraph is so spot on.

organizations have limited "focus" - it is even more scarce than money, or people. if you squander that focus on a process that doesn't matter (much), you are really doing a disservice to your team. Focus on what matters. Think of spending focus like an investment with an expected return.

that third paragraph is amazing. It sounds like they didn't even use a BPM Suite to do their "BPM" implementation. *facepalm*
  1. Scott Francis
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Peter Johnston Accepted Answer
There is a simple, though rather uncomfortable answer here. The key to BPM Adoption is us.

BPM is about hiding complexity, to make things so simple any idiot can do them.
So why haven’t we made the adoption process just as easy?

Is it that…

1. We actually like complexity?
Makes us feel we’re the boss and we know something they don’t. Like a carpenter or car mechanic who whistles through his teeth, says “it’s the thongesplangler luv. They all do that. Bugger to fix. It’ll cost ya”.

2. We don’t trust people?
We would rather impose our solution than help them create theirs. So we keep the smoke and mirrors to stop them asking questions.

3. We need to make it sound complex to justify the price?
IBM could create a simple price for IBM BPM and publish it on their website – but instead they force you through partners and even they take several days to get a price from IBM. Scott Adams created the word “confusopoly” for this – he said it was to hide the price so no-one could match or beat it.

4. We’re so stepped in old BigIT methods we’ve forgotten how to do something end-to-end on our own?
Even with big systems like Pega you can actually get a process up and running in a couple of days and present it to the business. Why must it take us months and a whole relay race of people – analysts, architects, developers?

5. We can’t actually do BPM on ourselves?
Perhaps we need to apply Lean principles to our own output. Cut out the waste and cull a process from months to weeks to days to minutes.

6. We like spending other people’s money?
Perhaps when it isn’t your money you take less care of it. So ROI comes secondary to six months at 1,000 a day. Before we know it we are mired in project bloat.

7. We need to lie to get the deal?
We all know that BPM works best end-to-end. But no-one will allow us re-engineer their whole business. So we worm our way in and become part of the furniture, so that when the next project comes along we’re in line for it.

8. We don’t know how to sell?
The essence of selling is to break things down into simple decisions which draw people through. A clear proposition. Obvious ROI. A path to the board for the person who adopts it. All the hassle taken out of his hands – it just happens. And an ocean of case studies to reduce the risk in their minds. Why can’t we achieve that?

Or is it that the customer doesn’t understand, the price is too high, people don’t know they need it, it isn’t core, others brief against it, blah, blah, blah. Don’t those begin to sound like excuses?

Isn't it us?
Dynamic Process
Oxfordshire, UK
+44 (0) 1491 874368
+44 (0) 7590 677232
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Ken Schwarz Accepted Answer
Why do some initiatives fail while others succeed? A good technical solution is necessary, of course, but projects rarely fail for technical reasons. Rather, it’s the people side—leadership and adoption—which tend to make or break the initiative. The soft stuff matters a lot.

[*] People need to know why things are changing. Keep your BPM initiatives’ goals front and center. Make sure that your leadership articulates and helps build awareness of these goals, why they must be achieved now, and what happens if they aren’t achieved.

[*] People need to understand what’s in it for them. Make it personal and tangible. Use BPM’s collaborative design to capture their requirements directly in the system and immediately demonstrate to them how the system will work. If it’s not right, fix it right then and there. They will feel ownership when they know that they have been heard and understood. Resolve or escalate when you discover misalignment of outcomes expected by your project sponsor and individuals’ organizational and personal goals.
Ken Schwarz Director, Product Marketing, Pegasystems
Ken Schwarz is Product Marketing Director for Pega Business Process Management and Dynamic Case Management solutions. He is an expert in enterprise middleware and its application to business transformation and competitive strategy. Ken’s career spans marketing, competitive intelligence, international sales, technical service delivery and product development.
First paragraph says is all, it's that simple. Attention span, "stick-to-it've-ness."
  1. Patrick Lujan
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
E Scott Menter Accepted Answer
Blog Writer
Approach the problem in the way that is best for the business => Receive funding
Approach the problem in a way that is easier and delivers greater value for the users => Improve adoption

No reason we can't do both.
http://www.bplogix.com/images/icon-x-medium.png Scott
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Scott Francis Accepted Answer
Blog Writer
Adoption is an interesting subject.

Adoption by end-users? Then the emphasis should be on user experience, value to the end-user, and self-help or self-servicing capabilities. While you're at it, try to make it so that you aren't throwing up barriers to IT adoption as well, so that users are free to choose.

Adoption by the enterprise or management? Then the emphasis should be on tools, visualization of information (especially that which communicates ROI and business critical decision data), and ability to adapt over time. While you're at it, make the user experience great so that the IT and business leaders who champion it won't be embarrassed or reluctant to roll it out!
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Ian Gotts Accepted Answer
Adoption inevitably means change. Change to a new way of working, or change to the working consistently. And most people are uncomfortable with change. Some are ok, some hate it and some will comply with the right incentives (stick and carrot).

Getting adoption is all about momentum. Get those who embrace change on board, and then the middle group. Often change programs spend a huge amount of energy on the naysayers, trying to persuade them to change and keep them changed. Instead, simply ignore them - they will either join in caught up in the groundswell or leave the company.

Look for radiators, not drains.

Dave Stewart, Eurythmics talked about radiators/drains on a national UK Drivetime radio show a while ago . They searched on Google and my blog popped up. Voila. A revised version of the blog is here http://wp.me/pLuvX-Rh My radio slot was 18mins long and included a couple of non-PC remarks (no surprise there) - but sadly it is no longer available on BBC iPlayer.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Shelley Sweet Accepted Answer
Blog Writer
I harken back to a seminal article I use in this regard from 2005 HBR, "The Hard Side of Change Management." It uses 4 criteria to determine the likelihood of success or failure or a project: DICE - Duration to implement, Integrity (performance capability of team working on it), Commitment of the executives and employees and Effort (how much effort on top of regular job that it takes to do the change). It then provides a scale and you can self-assess and see, based on the total score. what the likelihood of success is. And to me all four of DICE elements impact Adoption.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
John Morris Accepted Answer
If we believe that BPM is "the" technology of business (on the basis that "business is about work, and BPM is the main or only technology explicitly about work";), then BPM adoption is very important for business success, at least insofar as business depends on technology.

The assumption of today's question is that BPM technology adoption (defined most broadly as including technology and methodology) is lower than hoped for, or less than expected, or even disappointing. And the answer provided above are terrific.

Here are some additional thoughts as to why BPM technology adoption is lower than we would hope, given the promise:

1) TECHNOLOGY MATURITY -- The sales pitch for BPM is great, draw how you want your business to run, and then simply build out the processes to match. And voila! But the reality of "solving a graph in real time" is that the gap between modeling and execution is wide. And once deployed, if you've added so much execution specific information to the executable that your model is no longer in sync, then for all intents and purposes, you're locked in. There are methodological ways around this, but even then we a long way from our dreams of BPM. The result of the fact that BPM is harder than it will be, eventually, is that only dedicated IT shops, with very strong methodological discipline, patience and good communications between IT and business, are using BPM extensively. (There will be lots of little instances of "workflow" of course where roundtripping is not so much an issue.)

2) GOVERNANCE & ECONOMICS -- The BPM methodologies described above sound a little bit like Soviet-style top-down management. In this case business process becomes an effort of will. "Make it so". But just as Soviet management ostensibly eschewed "motivation" and economics, in favour of will, BPM and process governance typically do the same. Inside the walls of the corporation it's mostly command and control. And that C&C first of all bumps up against the technical complexity of BPM (per point No. 1 above). And then we ask ourselves why particular groups within a corporation may be happy or not with current practices. We can assume that at some level most people are motivated for goodness, and within a corporation, for the success of the corporation. But for a given process, is there motivation for individual groups of production workers, accountants, business analysts, plant managers, line managers, support staff, IT etc., to add to their daily workload while they build a new process, a new process that is personally risky? As well as dauntingly complex? And for the really juicy BPM projects which are cross silo, these concerns are especially acute. It's worth noting that the very centrality of BPM to what we do (i.e. "work";) means that BPM impacts corporate team members at the core of their relationship with the employer.

BPM technology will inexorably improve. And given the on-going rationalization of the corporation with new generation business process outsourcing, process governance becomes clearer and easier when what you do is so much more specialized. The BPM business may be a game of inches, but it is growing and will continue to grow, especially in hospitable environments where governance and economics are well managed.

It is said that "software is eating the world". An interesting extension of this question would be "what kind of software" . . . maybe BPM?
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Max J. Pucher Accepted Answer
Blog Writer
Ad-on Question: Did anyone tell billions of people to go out and buy and iPhone or to go onto Facebook? No. That is true adoption.

Yes, there was some advertizing, but people do it because it makes their life easier and better. They can do more and feel more powerful than before. That creates adoption. And that is the crux with BPM. BPM is about control and governance and the last thing it does is to empower people. Excatly the opposite. If you look for adoption with orthodox BPM you won't get it. it is hard to do in IT, hard to do in business analysis and dumbs down the business user. BPM creates fools with tools!

If you really want to empower the business the BPM solution they use needs to speak business language, which means it has to center around an ontology and allow them to perform actions based on what they know, not on what they are being told to do. All the rest about the need for executive sponsorship, commitment, governance and momentum shows clearly that BPM is not about adoption but about enforcement.

Rather than documenting, writing specs and desiging forms with the endusers, let the business define their work themselves, but that is most obviously not a BPMN flow diagram. Let the business improve processes as the work while they work by simply doing things differently than before and retaining that information. If you have exclude some people and work with power users you are already on the wrong track. If they need to learn some software then there won't be adoption. BPM has to speak business language.

The current BPM market won't get to this point because they are stuck in the flow-diagram rut. To propose that current BPM will evolve is nothing more than a ruse to keep people hanging in there. It has to be very different software than the current outdated BPM technology. Flow. daugrams are at best a perspective into the defined process but it doesn't actually control a flow. Real-world processes are state/event/action driven and do not totter along a silly flow.

Modern process management is additionally goal-oriented and adaptive and does not need a huge technology stack and governance bureaucracy. People know WHY they do what they do and the system empowers them to do it all within the BPM solution and they do not need MS-Office and email to execute their processes. It is a collaborative support layer on top of current IT and empowers the business users to better serve their customers (internal and external ones).

Yes, Marc Andreesen said that software weill eat the world but he most certainly was not thinking about BPM. BPM will eat itself if the BPM experts don't learn to put the human in the center and not a process illusion!
Actually yes, lots of people told billions to buy iPhones and go onto Facebook (for iPhone - see advertising budget of several large telecom companies plus Apple... no BPM effort has an ad budget like that :) ... and there are probably more blog posts about getting people onto Facebook or why their business should have a presence there than there have been on BPM i'd warrant :)

but, to your point, when the products/services offer enough value (viscerally not just measured), adoption generally takes care of itself ;)
  1. Scott Francis
  2. 3 years ago
"….stuck in the flow-diagram rut" Max you need to get up to speed with latest thinking - and come to think of it original business thinking.

I agree BPMN not really up to the job and needs to move on...? But frankly if you can articulate what people do to achieve an outcome then you can show in a graphical diagram formal or informal and if you can’t articulate you have a business problem! This was being implemented in the 70s by auditors to great effect ....until IT came along and the dark art took over and people had to mould to the system and what a mess we now have.

"BPM" now has the knowledge and technology to address next generation digitisation. This does as you suggest at a click of a button once you can articulate the process in business language via a graphical interface much much more than a "flow-diagram"……
  1. David Chassels
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Scott Cleveland Accepted Answer
BPM is a discipline – It is an ongoing activity. It will make a positive difference if it is done properly. A strong champion can act as a pied piper and lead the adoption of BPM within a company. They will act as an internal salesperson selling to management and users alike.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Amy Barth Accepted Answer
Based on the premise posed by Mike Gammage ("But come back a year later and it is, too often, in a slow decline";), the problem is a human one. The mission was accomplished, everyone high-fived, carried on, and got comfortable. If there's no intention to maintain the solution/process, then we will eventually let things slide. Other projects happen. People change jobs or leave. Life goes on.

BPM Adoption Management is often considered to be an "initial stage" undertaking, though it probably should be a constant feature of BPM Solutions. A BPM Center of Excellence can be a handy means to assist in the upkeep of BPM solutions, including conducting ongoing and intentional Adoption Management practices that serve as a means to maintain.

Also, it seems like there is an attitude of "thank you, we've got this, you can leave now," from clients toward their contracted BPM providers. But they don't "have" it. So, a year later, they'll start losing the edge that experts could have provided if they were allowed to continue the shepherding process.
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Firstly, I think, the question is about evolution at the time scale of solution/capability life-span not project life-span (sure that the former is several times longer than the latter). Usually, architects works with longer time-span than traditional project teams and architects guarantee that new capability/solution is easy to evolve after the closure of a related project.

An observation specially for Max, 3 years ago when the users started to use iPad, the client relantionship IT manager claimed that iPad will not need the IT department support & interventions because iPad makes users life easier and better without IT. 1 year later, after the sufficient proliferation of iPads and apps, the IT department started to guide the users about iPad and offered support for recommended apps and configurations.

Secondly, as BPM is the enterprise-wide transformation, we have observed that a BPM initiative requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM enterprise-wide practice. Each group of stakeholders has different views, different concerns and a different understanding of the BPM practice.

It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better. This is a typical duty of the chief architect of the enterprise BPM system.

Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying “Yes” to all requests from the “more important” staff members; it is about building a common understanding and agreement between all stakeholders.

Thirdly, a proper architected and implemented enterprise BPM system makes easier each next BPM project – more ready-to-use components are available, processes patterns are in place, business is familiar with a modelling procedure, line managers know to handle processes, IT department is comfortable with process-centric applications, management gets quick new KPIs, etc.

Is there an architect in your BPM initiative?


P.S. In my definitions, BPM is a trio of methodology, practice/architecture and tools. BPM offers several techniques for coordination of business activities; classic template-base coordination is only one them.
So true! Architectural thinking and leadership are essential to the long-term viability of a large-scale BPM initiative. In my observation, the most successful BPM initiatives have at their core a repeatable model which can be scaled out across the enterprise. These initiatives begin with a demonstration of success in one product line, customer segment, or region. But then they are expanded and rolled out to others. Behind them are sound architectures that balance the desire for standardization with the local needs for specialization as well as the teams and expertise to support them--often, a CoE.
  1. Ken Schwarz
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Bogdan Nafornita Accepted Answer
Key to adoption is ease of insertion into existing workflows.
Managing Founder, profluo.com
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Michal Rykiert Accepted Answer
End user interface - simple, intuitive, helpful and homogenous.
  1. http://www.bpmleader.com/2013/07/26/4-best-practices-in-creating-an-interface-in-bpms/
  1. more than a month ago
  2. BPM Discussions
  3. # 16
David Chassels Accepted Answer
A BPM "expert" turning up using such words as "......documents and metrics and systems. They wrap it all within a governance framework" is a sure way to gain short term even cynical interest.

"Adoption" is the point at which users realise they can have say and contribute to how they work. Best summed up by a real quote from a user “It captures all my weird and wonderful ideas and all done without telling me that I am expecting too much!”
  1. more than a month ago
  2. BPM Discussions
  3. # 17
Shreya Muralidhar Accepted Answer
To fully achieve the value of BPM an organization should make it part of its culture – i.e. its beliefs and practices – just as it may have done with respect to customer satisfaction or quality. It must evolve to become a process-managed enterprise. BPM Institute defines a process-managed enterprise as one that is structured, organized, managed and measured in terms of its core business processes. A process-managed enterprise exhibits these attributes:

Process improvement is embedded in the business strategy
Competitive advantage is supported throughout the value chain
It practices process-driven budgeting and resource allocation
Key processes flow seamlessly through the value chain
  1. more than a month ago
  2. BPM Discussions
  3. # 18
  • Page :
  • 1

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