We’ve seen it before -- the next big thing the analysts push that everyone has to implement to be “doing it right.” BPM has had its time in the sun for the past few years, and we’ve baked it into our software during that time -- what can we learn from the BPM projects that have succeeded and those that have not?

The Promise

The promise of BPM is obvious enough, and we’ve all heard the pitch -- it’s software development through drawing models and configuration... look ma, no code! Your analysts will be cranking out enterprise-grade applications over their lunch-breaks, and the measurement of every input and output of the entire enterprise will be at your fingertips -- you can make sense of it yourself with a few clicks!
You might, with some measure of discernment, notice that the BPM vendors you talk to are very different sorts of organizations. There are offerings from all the major stack vendors, many of whom have gobbled up several smallish other BPM companies, and either tried to meld them together into one or promote one while quietly snuffing out the others. Then, there are the pure-play “what we do is BPM” companies -- generally much smaller, but with a much tighter focus on their product and message.
Within either of those two categories, the BPM software itself can be broken down into several different types, with different backgrounds and therefore a different take on what constitutes BPM, as well as different approaches to reporting and data analysis -- but more on that in another article.
Let’s get down to brass tacks. How have things panned out? What can we learn from the past few years of implementing BPM projects?
Let’s start by understanding that talking about “BPM projects” in a general sense covers a wide range of different types of software projects. Think about your own organization. Why did you implement, or why are you thinking about implementing, BPM? Is it to build departmental or point solutions, or impose top-down policies and work measurement across the whole organization? Do your processes include many external systems and integrations? How extensive of a set of configurable business rules do you have and how complex are they? What are your security requirements? So right off the bat, we’re not talking about apples-to-apples comparisons between “BPM projects,” as such. But is software through drawing pictures a reality or pipedream?
Yes. I’ve seen it done. I’ve done it myself. You can use most of the BPM tools out there to model various interactions between actors (users and systems) and implement in some form or other the input, manipulation of, persistence of, and reporting on an organization’s data. This will generally include: the ability to create forms (often with a drag and drop form designer), assign tasks to users, interact with databases and web services, orchestrate the passing of data between systems, set alerts, escalations, and events. You can take this data and combine process metrics and business metrics / data to gain real, valuable insights into how your organization functions, making management a much more quantitative science.
Done right, BPM can indeed deliver on (well, most of what) the vendors pitch.  Pick the right tool, put in place the right development practices and quality controls, understand the bigger context of how you want BPM to fit into the organization, build operational processes and reports that provide value to the business, get stakeholder buy-in.  In short, do everything right (low bar, right?) -- we'll conver the details of that in a later post. 

The Peril

Just as a baseline, let’s assume that “doing BPM” means having some sort of modeling environment in which you draw / connect a series of flows of human tasks and system tasks and those models are executed in some runtime environment on either a short-lived or long-lived basis. Across the spectrum of BPM products, where we go from there and what it looks like and how it works varies widely.
That point (that there is a wide array of very different products in the space) means that often your BPM implementation and its success are either strongly aided or hindered by your very first choice -- picking a BPM product. Sometimes -- often? -- that decision is made for you and you’ve got to work with what you’ve got. Sometimes it’s embedded in a product your organization uses and you really don’t have a choice. It’s a crucial factor in your project’s success -- do you need strong system-to-system integration and orchestration? Do you need document storage and approval routing? Are your processes very human-to-human oriented? There are (several) BPM tools that are very optimized for each of use cases, and there are some that fall flat on their faces when they are (attempted to be) used for a particular use case.
Another critical factor that will influence whether your initiative sails smoothly is how management aligns behind a BPM initiative. Is this a “toe-in-the-water” effort? Is it coming from above as a strategic initiative, or is it an experimental new-technology spitballing in some fringe IT or software development department? Unless you view BPM simply as a means-to-an-end rapid application development tool, it probably matters to you that it is an efficiency enabler for your entire organization -- not just a single process (although, again, it’s not to say that isn’t a valid goal in some cases). Without the backing of the powers that be, implementing a BPM initiative across the organization (and really using it to its full potential) will be greatly hindered.
Another potential pitfall when implementing applications in a BPM tool is one familiar to any software architect of any background: your development tools (especially programming languages, but it applies elsewhere too) need to allow you to tackle complexity by allowing you to work at the correct level of abstraction. One qualitative measurement of this would be to show your BPMN diagrams to a business user (not a developer). Can they look at your implemented model(s) and recognize it as the actual processes which they carry out in their daily work (or the work of those they manage)? Often the hairy details of implementation sneak into what should be a clear description of a business process, killing one of BPM’s biggest potential payoffs -- allowing developers to work with business users to discuss the behavior of the application and how the organization does or should operate. If your BPM tool forces you (or even if it allows you and you either wilfully or accidentally follow that treacherous path) to litter your process with incidental complexity and implementation details (“increment counter”, “map X to Y”, “prepare business object Z”), you’ve lost business users. You simply can no longer discuss the model with them at the right level of abstraction for it to make sense.
This raises another point. Almost every BPM vendor pushes the notion that their tool finally achieves the dream of letting business users create applications without the aid of developers. This is simply a pipe dream in most cases. There is a reason it’s hard to recruit good developers. Creating software is a complex undertaking and most people, whether through lack of ability or inclination, don’t think the way you need to in order to implement anything other than the most simple of applications. (The example I usually use here is my mother. No offense to her -- I lived with her for the first eighteen years of my life, and I know she’s a very smart person, but there is NO way she will ever create a functioning piece of software.) Another issue is simply one of quality controls and enforcement of policies, style guides, and best practices. Once you open up the creation of applications in your enterprise to “everyone,” how do you enforce those controls?

The Payoff

The truth is -- it’s scary out there in the real world. You’ve got analysts telling you what you need to do, but coming up short on telling you how to do it.  You understand the potential payoff and pitfalls, but you’ve got to make a lot of decisions and everyone from the business analysts to the architects to the developers to the stakeholders need to be pulling in the same direction for the project to be successful. Things can and often do go very wrong. The truth is that BPM, however, assuming you’re using the right tool for the job and using it correctly, can be both a rapid application tool AND an efficiency enabler in your toolkit, enabling a shift in the way you build and deliver software to your organization -- not to mention being a force for transformation towards efficiency and operational intelligence through the organization as a whole.