As a professional in the BPM space, I’m continually reminded of the challenge of defining what BPM really means. For some, this is an issue of perspective as IT people see BPM as automation of work and business people see BPM as the means of managing human to human and human to technology interfaces. There don’t seem to be too many people on the sidelines, either. Add to the mix the more recent clamor around adaptive case management and social BPM, and you have the recipe for ongoing debate and confusion.

For those of us in this space, we would be doing the world a great favor to cut the rhetoric that reinforces a narrow point of view and begin talking about business process management in more specific terms, like the desired outcomes of our initiatives. The fewer times we use the word ‘process’, the better. At the end of the day, we need to define the expected return on investment of an initiative and that calls for specific language.

Part of the problem may be that we aren’t completely sure of the ultimate value of “just doing things better” and so we hide our own skepticism behind grand terms like, “process excellence.” What does that really mean? I have no idea, personally…and if I can’t define it in tangible terms, there’s no way I’m going to get budget or get executive and colleague buy-in.

In the end, BPM is the entirety of the way work is done in an enterprise. From the most creative exercise, like brainstorming, to the most automated, like routing of email, all of the behaviors that we call ‘work’ together make up business process. All of it. Some activities can be easily captured and some are more elusive. Some work can be automated and some may never be. More than anything, we need to accept this wide view before the dialogue can be meaningful.

Since it has many facets and even opposing characteristics, managing business process can’t be done through the use of any one tool or system. I’m sorry to inform you that business nirvana won’t happen with the purchase of Product X, Y or Product Z. We can only understand what we map at increasing levels of granularity, and then we can only manage after we decide our goals as tangible outcomes. If we want to cut costs, we can then look at duplication, poor handoffs and rework. If we desire better customer retention, we can try to improve specific customer-facing activities that affect that outcome.If we desire automation, we can look at what humans do and find ways to route and process data with less human intervention.

But we have to start with a view of the organization that puts everything else in context. The more we try to solve with a single approach, the more likely we’ve commoditized the execution of our business and killed agility.

Follow