BPM IS BPS

The organization and website name by which it goes, BPM.com, took on the challenge of clarifying just exactly what is BPM. In conclusion they’ve defined BPM as:

“Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.”

They indicate that the process of creating the definition took 10 years and was executed though contentious debate within themselves and with industry experts. It certainly does read like it. It’s one of those definitions that by the time one gets to the end, the middle is hard to recall precisely and the beginning is a distant and fond memory. It does successfully expose the breadth of the term and the lack of clarity in its use.

Most importantly, though, it identifies that BPM is a discipline.

Business Process Management is hardly new. Some business historians place the genesis of BPM in the 1870’s, around the beginning of the Second Industrial Revolution. It was a time in which major businesses were growing larger and more complex than any non-government entity had ever been up to the time. Manufacturing as well became more complex and functioned at higher volumes with more personnel and materials. Other historians place the beginning more than a hundred years earlier with the arrival of the first Industrial Revolution.

As organizations began to grapple with this new level of scale and complexity in business, sourcing and manufacturing processes a new, scientific perspective on the functions of a business was needed to maintain efficiency and profitability. Hence, BPM. And in that context, the moniker fits. It truly is a business process engineering discipline used to effectively and efficiently manage the varied business processes of a company.

InterImage has built many systems that were called BPM solutions for customers over the last 20+ years. In those engagements we would universally go through the steps of meeting with the owner of the project to identify the intended scope, our analysts then meet with the intended users to learn the business processes, the workflow of what they do day to day. Our technical team takes that documented body of knowledge and architects a software product that fits the existing workflow to facilitate the work being performed by our customer. One or more cycles of software development, depending on the methodology be used, are executed including testing, bug fixes, and functionality modification and expansion later. The process is completed with user acceptance and deployment.

By its very nature, what we have built directly mirrors and supports the existing workflow of our customer. It does not manage what they do. It is not business process engineering. That is a different thing and we have done that, too. But the process and outcome are not at all the same. That is what we do when a customer is standing up a new business environment. It is not business process re-engineering. We do that as well. That’s what we do when a customer wants a fresh look at how they do their job all day every day. A refresh look, a new evaluation of existing business processes is not a bad idea. Many organizations function with business processes that evolved decades in the past before the modern technology revolution. Sometimes there are better ways to do things that weren’t possible many years ago.

What we are actually doing is building Business Process Support (BPS) software. The software we build does not manage business process, it doesn’t define business processes new or old, it supports business process that are for the most part, as in 95%, already in existence.

When software and application development companies are hired to build BPM solutions, they are in reality building BPSS solutions. BPSS, BPM, what difference does it make what we call it? The difference is quite important. By correctly identifying the effort organizations will more clearly see the true nature of the product or service they are buying and will far more easily identify the needs that it can answer and the overall value it can be expected to bring. Not only will the appropriate scope be more obvious, the answer to the very question of whether or not to spend money on the effort will become completely apparent.

If I call a Smart Car a van I’m going to be disappointed when I go to pick up 4 friends and their luggage. If I call a pick-up truck a sports car I’m going to be very disappointed when I try to go blazing around some winding back-country roads. If I call a business process support software project as business process management project I’m already starting out in the wrong direction and before the project even begins I have to work to get the project back onto the right track.

We build BPS solutions. So do many of our competitors. We need to stop calling them BPM solutions. And so do our customers.