Last month I received a copy of Dr. Setrag Khoshafian's latest book, "Intelligent BPM: The Next Wave for Customer-centric Business Applications." I had peer-reviewed an early version and offered a jacket quote, but in all sincerity had I come across it any other way I would have bought it immediately. It's quite good.

Dr. Khoshafian is someone I have known for many years, back to the 1990s when he was the head engineer for the company that later became Savvion. He joined Pegasystems in 2003 (from Savvion) where he serves as Chief Evangelist and VP of BPM Technology, but his street cred and contributions to the evolution of BPM transcend any single vendor.

The BPM (Business Process Management) or business management by processes has been the subject of several definitions and approaches depending on the perspective of the interests of its authors, but we can synthesize in two major tendencies, one more IT oriented and other more concerned with the management of the business itself. The IT approach is more focused on modeling, automation and execution of processes, supported by tools of BPMS (Business Process Management Suite) while the management approach aims to ensure the achievement of strategic objectives, seeking to maximize efficiency through the processes, and thereby achieving greater profitability of business operations. It is in this vision that this article should be understood, leaving specific aspects to the reader, essentials to the BPM approach, in order to help organizations ensure real business benefits.

All of us like practical tips that we can read quickly, use easily, and produce results. Since I began blogging two years ago my focus has always been on writing about my experience with clients in the BPM/Process Improvement field—or what a colleague of mine calls providing, "Notes From the Front."

My new book, The BPI Blueprint: A Step-By-Step Guide to Making your Business Process Improvement Projects Simple, Structured, and Successful, just published in February and available on Amazon, is a practical guide tells you exactly what's required at each BPI phase, and techniques are explained so you can replicate them.

Here are "some tips for the road" that you will make your BPI project successful and there are many more in the book.

Over the last 12 years, I've seen – and helped drive – a lot of change in the BPM market.  First, I watched BPM move from a heavy focus on integration to a greater focus on collaboration and social interaction.  And then, BPM expanded from highly structured and ‘automate-able’ processes to address unstructured, more dynamic business processes.  It is safe to say that over the last decade, demand for BPM was driven by key characteristics of the "Information Age" - a relentless drive towards improving the flow and sharing of information across people and systems.

Now, the most compelling business cases powering fresh demand for BPM focus on characteristics of the new age we are moving into - what Forrester calls the "Age Of The Customer."  If you look closely at most of today’s BPM initiatives, they tend to hide behind an imaginary firewall that separates what external customers experience and what internal business operations feel they need to be efficient. In this new age, business leaders are waking up to the realization that they can no longer divorce process improvement from the people and systems that touch customers, partners, and customer-facing employees. 

Over the years, organizations have created "business processes" mainly to rein in the chaos that has proliferated inside their operations. They have installed BPM tools to automate their processes and make sure tasks can be repeated successfully over and over again.

This practice does a good job of restoring order, but it also has a downside. Installing a rigid process can create a system where an organization gets too locked into certain procedures and ends up repeating the same mistakes. What organizations need is a less static, more iterative approach that sets rules to bring order from chaos, but allows them to make changes easily when parts of the process become outdated, irrelevant, unnecessary.

As BPM suites mature, they have become more accessible to a broader range of users. Whereas in the past, the design of business processes was reserved to .NET and Java developers only, now user friendly wizards and drag-and-drop canvases have made it possible for non-developers to jump in and design BPM processes as well. Today, there is a dichotomy (certainly among our customers), with approximately 60% of processes still being built by more advanced developers, but a healthy 40% being assembled (for the most part) by what has become known as "Power Users". A Power User, for lack of a better definition, is a user who is technically oriented, but does not have coding skills or experience. My question is - should Power Users be designing processes? Is this optimal or efficient for a business?

Naturally, much depends on each individual user, and it's difficult to generalize. Some Power Users just get it, and some don't and should be left for the modelling sessions only. But if we take the average Power User, I think we can come to some conclusions. First off, in most cases, a Power User does need some setup and help from a Developer to get started. Form and Activity templates may need to be created, not to mention integration with external systems such as ERP and CRM. But once the environment has been set up sufficiently, our experience is that Power Users can and do succeed in building processes. Additionally, Power Users often have a broader view of the business (they are often also Business Analysts) and that actually gives them an advantage when designing processes for the business.

The major difference is in the complexity of the customization. If the requirements of the project include complex form functionality and/or a significant amount of integration, Developers are almost always needed. If the processes and their forms are relatively straightforward, Power Users can usually overcome most challenges alone - with some help from time to time where coding is necessary.

Another major factor is cost. It's a fact that a team of Developers is more costly than a handful of Power Users. BPM suites today (at least the more advanced ones) are much easier to learn than .NET projects. Power Users can usually be trained in a space of weeks, as opposed to the years it takes to master programming in Visual Studio. So a business that has Power Users at the heart of its process development will save costs, though it might have to compromise on some complex functionality.

Perhaps the most important result of this discussion is the trend. BPM Suites, just like most enterprise software, are moving toward the Power User. We can expect that that within 3 - 5 years, this trend will continue, to the extent that there will be fewer limitations for Power Users working on BPM projects, and less reason to touch the code. Does this mean the end of an era for Developers? Hardly. I believe that just as BPM products become simpler to use, so too business requirements will become more and more complex, and there will always be a healthy chunk of work for Developers going into the future. As such, the right strategy for a BPM roadmap is to plan for teams which incorporate both Power Users and Developers among their ranks.

Eli Stutz

Head of Knowledge and Collaboration, PNMsoft