The Business & BPM

Confusion and Coherence.

This one is short and sweet. Sometimes even I can be concise.

The phrase “Business Process Management” represents a philosophy, a set of interrelated technologies and mechanisms for discovering, defining and managing business processes. It includes many subcomponents such as business rules, workflows, metrics, reporting, decision support, profiling, process modeling, process analysis, automation and on and on and on. In fact, the term “BPM” is about as clear as the term “Portal” and often means different things to different people. And let’s face it, most of these people with differing views have, shall we say, strongly held differing views.

The responsibilities for various parts and pieces of BPM are typically spread across many different reporting structures. Strategy, planning and execution are likewise spread out in various areas. Many of these areas don’t even know the others exist, let alone work closely with them.

A Few Questions for You.

So, when the business launches a project and comes to believe they need  elements that we in IT would classify as falling under the term BPM, how  do we deliver in a coherent fashion? How do we deliver value to the business in the area of BPM? What is an effective way to ensure standards and reduce variability when delivering BPM to the business? Is the key governance? Does a well-run EA program solve the problem? How about effective management? Personal relationships that cross the IT-Business divide? All of the above?

Business Solutioning.

The business often gets confused about their role. Too often they begin a project by attempting to negotiate or dictate a solution to IT. The reality is, of course, the business’s first objective is to understand what problem they’re trying to solve (instead of how to solve it). Second, by using business-enabling technologies like process modeling, the business must understand their…well…business. Understanding how they do what they do today is simply a prerequisite to any further activity. After they understand how they do things and why they do them, they can begin to understand why they want to change and why they need IT to help out.

Frankly there is no way for IT to devise an effective IT solution if the business doesn’t know what they do, how they do it, or what they want to do in the future (i.e. the capabilities they want enabled). If those things are in place, the technology part can be incredibly easy.

Tech is Easy.

In fact, one of the techno-crytpo-philosophical statements I frequently make in my consulting work is “technology is the easy part.” Because let’s face it, if you understand you have a business problem and you understand that business problem, solving it with technology becomes almost academic. Almost. Because you still have that other massive, hulking, looming gorilla in the room: People. But that’s a problem for another post.

That’s my take on it in 500 words or less.

What do you think? How much of BPM is the responsibility of IT? Is BPM a technical thing at all? Is it an outmoded term?