What Comes First: the Process Improvement Methodology or the BPM Software?

Process, process, process every time. If you don't have a process to improve process, what good does a tool that does it do?

Clearly someone in the organization has to have the desire and have thought about an approach to improving process before getting BPM software. Widespread adoption of the methodology will be aided by the use of the right BPM software.

Automated Process Discovery (APD) however can come first as an upfront analytic technique which can measure how much there is to gain from process improvement. This is clearly recommended since implementing a new methodology or purchasing BPM software can be expensive, and the APD can be a big help in doing the cost justification.

At the Gartner BPM conference earlier this month the analysts felt very strongly that customers should not let BPM vendors or their technologies and demo's drive the project.

The best case scenario should be a blend of a number of sources of input - technology, business, process....it is more critical to have a methodology that is flexible and can accommodate changing definitions.

See Pega's press release from this morning - http://www.ebizq.net/news/11835.html?rss

Both in parallel would be ideal. Some tools contain built in reference models and frameworks to help organizations structure business processes around industry standards (see bit.ly/2SQNvs) as well as incorporate support for business improvement/quality disciplines like Six Sigma. These capabilities combined with vendor expertise on how to get the most out of the tool help ensure you actually get results - versus getting caught up in endless, theoretical process improvement exercises.

I thought we had beaten this topic to death in this forum.

The tools just support the methodology.

As for the specific question asked, using a vendor-devised methodology is a recipe for disaster. There is some great work of standards bodies that included real practioners efforts that I would follow before ever following a vendor-specific methodology.

The wording of the original question shows an obvious bias, especially the phrase "proven, generic process improvement methodology." Is there really generic methodologies that have been proven to work in all kinds of business cultures? The most effective process improvement methodology will be one that is tailored to the culture and realities of the organization that is doing the work, with a consideration of the strengths of the BPM tool that is being used.

I'll chime in briefly as the originator of the question. No personal bias was intended to be reflected in the question (I originally come from a BPM vendor background, so it would be an odd bias to have, though that could explain a lot), just an intention to provoke some reaction out of a tech heavy contributor list!

My take is a little like all the others, with an important caveat which I think reflects the fact that a lot of people have quite a narrow view of BPM.
In short: if you're in a position to use a process improvement methodology, it's likely to be a good idea to at most blend a vendor's approach with something more industry-standard.
Here's the caveat though: methods like Six Sigma and Lean are great at helping you with *continuous improvement*. That's something that equates to something like CMM Level 5 in terms of process maturity... so what happens if you don't have a well-defined process already, and you need to get some order to your work, quickly? Six Sigma and Lean won't help you (they'll come later, if you're lucky). If there's more of a transformation requirement on the table then actually, a lot of what the BPM vendors and SIs can do can be pretty useful.

I tried this same question on a discussion group primarily on business process improvement from a methodology standpoint (the LinkedIn Business Process Improvement group). For them there was an strong desire by many contributors to say that technology just gets in the way of processes, though there were some balancing opinions. The discussion was lively with somewhere close to 40 extensive responses.

From that discussion, I would like to pass on these particular themes before relating my own opinions:

A 'process improvement purist' would suggest that we analyze and correct the process first, get the waste out of the system, then we have a bunch less work to do to implement a new process, be that manual, software or some combination. An alternative argument is this: if we focus on technology at the start, its like brainstorming, you instantly limit your mindset and the potential methods for improving the processes.

As a 'process/technology pragmatist', one would go with the idea that most BPM and related software more or less does the same thing. So feel free to improve the process in the abstract, and use the software you have to hand to implement it. This argument in fact suggests that the vendor 'arms race' leads to a bunch of indistinguishable products, so go with the cheapest, most pervasive one out there.

As a 'technology purist' (probably a vendor) I would probably insist that the technology can guide my designs and offer huge benefits from its unique capabilities and features. Design the process around the technology, since you'll get the best benefit from it, rather than fighting the tide of the software you are going to ride anyway.

Based on this, I would offer my personal opinion. All of the above business process sects have their value. For any one of them to work well it requires years of experience watching clients try and fail, try and fail, and try again and succeed in improving their processes. Based on that experience, in any particular scenario the experience leads you to know how far to push any one approach, and which blend has the higher chance of success.

My professional bias right now is technology focused, since I believe there is the opportunity to significantly reduce the time wasted in the complex analysis and software projects always required by BPM for even the simplest of processes.

Phil Ayres
http://blog.consected.com
http://www.consected.com

Tad surprised this question is here, especially as the answer is so obvious (everyone here agrees, little discussion)

I always try to keep things as simple as they can be. So BPM projects can be broken down into:

1. Someone has the drive within the organisation to improve efficiency
2. A methodology is chosen if you like to identify processes, change and improvements (could be a consultant doing this)
3. Areas for automation are identified along with integration with other LOB applications
4. You start to look at BPM software that will enable you to deliver

Dont ever let a BPM or ECM demo decide what you want to do or what you can acheive...

It seems a shame that many contributors are assuming that the company making this decision does not already own one (or many) BPM tools, and are about to be sold by a slick selling effort. Maybe that represents the state of the industry, that too many companies become disillusioned with BPM after it fails to deliver what they hoped, so everything is a new sale. (Or we are all vendors focused on our sales and marketing efforts!)

But just imagine an imaginary company is lucky enough to own a tool already. What would you do? Use the tool you have, and let its own strengths force the direction, or the methodology that knows no technology, and delivers a design that fails to fit the best practices and strengths of the tool.

It has been interesting to see the many ways the question could be interpreted in any case.

As a “Process Improvement Purist”, I use a “proven, fundamental” mapping tool that was introduced to business in the 40’s and its symbol set was adopted by ANSI and ASME as the standard for Process Charts in 1946/7. In my experience (30 years) it has never required failures to achieve successful outcomes and has been absolutely appropriate for every type of organization that I have worked with. While the maps are far more detailed than most, they can be prepared by a skilled analyst quickly and thoroughly and are easy for people at any level in an organization to work with (I have worked with folks on loading docks, in data entry, in accounting, in factories, out on oil rigs and in warehouses; I’ve worked with clerks, attorneys, analysts, engineers and executives) and not one person who has actually worked with one of these maps has ever commented negatively on its value…They have been universally accepted by the people who do the work as well as by IT folks and developers as a tool that really helps them understand process… something that no BPMN or box and arrow mapping tool can claim. Graham Process Mapping was developed at the Standard Register Company by Ben S. Graham in 1944. One of the beauties of this tool is that while it comes wrapped in a fine methodology (the work simplification approach) it can be used to support any improvement methodology and will provide tremendous up front value for any new software implementation or expansion.