Oversimplifying BPM, Part I

I recently met with a customer that uses Pega for one of their mission-critical, enterprise-wide business applications.  They also have another BPM product that they view as their “BPM standard” and have built a small internal practice around leveraging that product. 

I was explaining to the customer how Pega helps organizations solve complex, mission critical business problems: things like exceptions management, investigations, customer service, sales and marketing, etc. 

The customer was surprised, because they had found with the other BPM tool that the best problems for BPM were the simplest ones: time off approvals, purchase order requests, etc.

I’m all for using BPM technology to tackle “low-hanging fruit.”  At Pega, we run everything from time and expense reporting to our employee review cycle to contract process on Pega software.  But I think that this perception to focus BPM on the “simple stuff” reflects the way in which most BPM technology has painted itself into a corner.

Every BPM platform is focused on providing an easy-to-use way for business experts to participate in, and even drive, the development of the applications that support their business.  Unfortunately, too many BPM platforms have dumbed down the experience to the point at which their customers can only use BPM for the simple stuff.

The truth is that enterprise software is hard. Transforming an organization is a knotty and complex problem. And while BPM should provide an easy entry-point and a fast learning curve, technologies that focus on simplicity at the expense of all else will never be able to tackle the complex, enterprise-wide  initiatives that can meaningfully impact an organization’s bottom line and improve the overall customer experience.

So why are most BPM platforms limited to just the easy stuff?  Why do they run out of runway when the problems get challenging, the scope of the solution widens or the volumes of users spike? In the next few blog posts, I’ll break down three key limitations in traditional BPM architectures.  I’ll also propose that we need to broaden our thinking about what BPM is, and what a BPM platform can do.

Coming up in Part II, I’ll talk about why traditional BPM platforms aren’t able to automate complex work.