To me, it starts with agreeing what "BPM methodology" means in today's age of phones, chat, gen X and Y workers feeling empowered at work and better ways to build culture and engagement without legacy BPM methods (as documented elsewhere).
Ultimately, the endgame here is that people will do BPM without knowing they are doing BPM - or even caring about what BPM means.
How we get there is what we're thinking hard about.
Here is your easy button: stop thinking about a business process as something that transforms inputs into outputs. Instead, think of it as a collaboration with many people doing many independent things that need to be coordinated.
There are no "Easy Buttons" on the road to BPM. Just as there were no Easy Buttons on the road to current accounting practices and technologies. And from an economic point of view, Easy-Buttons-as-competitive-edge should be selected out by competition. The history of BPM technology is proof of these assertions.
I haven't found any easy buttons in BPM implementations (granted, I never knew I was supposed to look for any).
BPM means constant change and change management is difficult - regardless of technology, methodology, consultants, management, industry. Trillions have been burnt into useless research, marketing and tech just to get back to square one: people seek and find comfort in predictable, past, patterns - it takes hardened skill (and will) to lead them out of those patterns and into new ones.
So, I agree with John and Patrick, with the comment to Patrick that his recommendation (which I absolutely love) is not really "easy" :-)
Considering that BPM is about better management of the business, BPM is similar to managing personal health. Thus it is easy to talk about BPM than difficult actually doing it (compare “I will jog 60 mins each day” vs actually do it).
Fortunately, BPM is able to convert a complex problem of “better management of the business” in a complex one “better management of the business by processes”. In accordance with CYNEFIN, a complex problem is addressed with trial and error way and a complicated problem is addressed with good practices.
Thus, BPM is actually the “Easy Button” for solving your current and future business problems. Is it easy? Technically yes, socially - all depends.
From the aspect of a more people focused process, the "easy button" is creating an abstraction for the users. The users of the process should be given an interface that let's them perform their work within the guidelines set by the administrator. The trick is to have all of the boundries the user will run into on the process feel natural.
An even more advanced form of this would be to allow for some users to dynamically define what the process is. Start with a process with the most common tasks and sequence flows, then let users define new sequence flows to existing/new tasks when exceptions arrise. This would allow the people doing the work to define the process that makes sense. Not just a couple people in a board room designing some "perfect process" that fails when implemented.
You would need to pick the knowledge workers that know how the business works and not the brain dead office monkeys. The system would need to provide analytics on processes to help identify superfelous tasks.
Of course there is more to this story, but that's my version of an "easy button" in action.
I can see the value of a separate discussion on each of the 19 topics
1. mapping out processes (concept level);
do we map using whiteboards/markers; post-its; e-mapping with BPMN; e-mapping not with BPMN?
do we do the mapping on-site or via a series of GoToMeetings?
are short, say, 1 hour sessions better? (hard to do on-site, easy to do via GoToMeeting)
do we use a BA/BI, or a facilitator, or make the customer build their own maps?
do you publish on a wall, on paper or electroncally?
The "easy" button is now the click from the model useing MDE no/low code that can build the required application ready to run...!
Hmm... but this new way never becomes "legacy" as it readily supports constant change and as for requirements no need for final spec just build direct from users input in recognition first cut will likely be changed with user feed back.
Here is the list of 19 "phases" of BPM
It would be nice to get an indication from commenters on which ones are recognized as being part of BPM, which ones are implemented at customer sites and what the E-M-D ranking is.
E=Easy M=Moderate, D=Difficult
I like the comment of Alexander : "BPM is better management of the business by processes". In this highly IT and gadget driven world is getting people to think processes, the most important game changer when you want to start improving your business.